Techniques for determining a state of proximity between mobile devices

ABSTRACT

Techniques are provided to support proximity services for a mobile device. In an example implementation, an electronic device may determine whether a first mobile device and a second mobile device are each operatively provisioned to make use of a common proximity service, and determine whether a state of proximity between the first and second mobile devices is expected to occur at a future time based at least in part on a current or past motion state of at least one of the mobile devices, and/or a historic behavior of at least one of the mobile devices, and/or an identification that the mobile devices are in a common venue. The electronic device may initiate notification of a user and/or an application of at least one of the mobile devices that a state of proximity with the other mobile device has occurred or will occur.

CLAIM OF PRIORITY UNDER 35 U.S.C. §119

This patent application claims benefit of and priority to U.S.Provisional Patent Application 61/735,490, filed Dec. 10, 2012,entitled, “DISCOVERY AND SUPPORT OF PROXIMITY”, and U.S. ProvisionalPatent Application 61/773,585, filed Mar. 6, 2013, entitled, “METHODSAND SYSTEMS FOR PREDICTING AND/OR DISCOVERING PROXIMITY OF MOBILEDEVICES”, each of which is assigned to the assignee hereof andincorporated herein by reference.

BACKGROUND

1. Field

The subject matter disclosed herein relates to fixed and mobile devices,and more particularly to methods, apparatuses and articles ofmanufacture for use by one or more electronic devices to supportproximity services for a mobile device.

2. Information

Communication networks enable communication between two or moreelectronic devices. Such communication may be used to enable and/orsupport a wide variety of different services. To name a few popularexamples, various communication networks may enable/support telephonecalling, video conferencing, electronic mailing, video streaming, aplethora of Internet-based services, location based services, and/or thelike or some combination thereof.

In a particular example, the technology directed towards wirelesscommunication networks, mobile devices and related services continues tochange and improve at a rapid pace. Indeed, the increasing capabilityand popularity of mobile devices such as smartphones, tablet computers,wearable computers, and the like, continues to spark innovative uses andcorresponding services and applications.

Accordingly, some services, applications, and/or other like processesmay benefit from a determination as to whether certain mobile devicesand their associated users may or may not be located nearby to oneanother, within a common area, and/or within a particular radio range ofone another, etc. For example, applications on mobile devices that arefound to be nearby to one another or nearby to certain fixed devices maybe notified and enabled to perform services of value to their respectiveusers such as notifying the users, establishing a voice or data sessionbetween the mobile devices without the use of an intermediate networkand/or conveying information to the users associated with an area theyare in.

SUMMARY

In accordance with an aspect, a method of supporting proximity servicesfor a mobile device may comprise: determining whether a first mobiledevice and a second mobile device are each operatively provisioned tomake use of a common proximity service; determining whether a state ofproximity between the first mobile device and the second mobile deviceis expected to occur at a future time based at least in part on at leastone of: a current or past motion state of at least one of the first orsecond mobile devices, a historic behavior of at least one of the firstor second mobile devices, and/or an identification that first and secondmobile devices are in a common venue; and initiating notification of auser and/or an application of at least one of the first or second mobiledevices that a state of proximity with the other mobile device hasoccurred or will occur.

In accordance with an aspect, an apparatus for supporting proximityservices may be provided which comprises: means for determining whethera first mobile device and a second mobile device are each operativelyprovisioned to make use of a common proximity service; means fordetermining whether a state of proximity between the first mobile deviceand the second mobile device is expected to occur at a future time basedat least in part on at least one of: a current or past motion state ofat least one of the first or second mobile devices, a historic behaviorof at least one of the first or second mobile devices, and/or anidentification that first and second mobile devices are in a commonvenue; and means for initiating notification of a user and/or anapplication of at least one of the first or second mobile devices that astate of proximity with the other mobile device has occurred or willoccur.

In accordance with an aspect, a computing device for supportingproximity services may be provided, which comprises: memory; and aprocessor to: determine whether a first mobile device and a secondmobile device are each operatively provisioned to make use of a commonproximity service; determine whether a state of proximity between thefirst mobile device and the second mobile device is expected to occur ata future time based at least in part on at least one of: a current orpast motion state of at least one of the first or second mobile devices,a historic behavior of at least one of the first or second mobiledevices, and/or an identification that first and second mobile devicesare in a common venue; and initiate notification of a user and/or anapplication of at least one of the first or second mobile devices that astate of proximity with the other mobile device has occurred or willoccur.

In accordance with an aspect, an article of manufacture may be provided,which comprises a non-transitory computer readable medium having storedtherein computer implementable instructions executable by a processor ofa computing device to: determine whether a first mobile device and asecond mobile device are each operatively provisioned to make use of acommon proximity service; determine whether a state of proximity betweenthe first mobile device and the second mobile device is expected tooccur at a future time based at least in part on at least one of: acurrent or past motion state of at least one of the first or secondmobile devices, a historic behavior of at least one of the first orsecond mobile devices, and/or an identification that first and secondmobile devices are in a common venue; and initiate notification of auser and/or an application of at least one of the first or second mobiledevices that a state of proximity with the other mobile device hasoccurred or will occur.

BRIEF DESCRIPTION OF DRAWINGS

Non-limiting and non-exhaustive aspects are described with reference tothe following figures, wherein like reference numerals refer to likeparts throughout the various figures unless otherwise specified.

FIG. 1 is a schematic block diagram illustrating an arrangement ofrepresentative fixed and mobile devices that may be used to determine orassist in determining a state of proximity between two or more mobiledevices, in accordance with an example implementation.

FIG. 2 is an illustration showing an example arrangement wherein a stateof proximity may be determined to exist between certain mobile devicesbased, at least in part, on distance and/or other geographicconsideration(s), in accordance with an example implementation.

FIG. 3 is an illustration showing another example arrangement wherein astate of proximity may be determined to exist between certain mobiledevices based, at least in part, on map and/or context consideration(s),in accordance with an example implementation.

FIG. 4 is an illustration showing still another example arrangementwherein various states of proximity may be determined to exist betweencertain mobile devices, in accordance with an example implementation.

FIG. 5 and FIG. 6 are illustrations showing some example arrangements ofmobile devices supporting the transmission and/or relaying ofinformation for use in determining a state of proximity between two ormore of the mobile devices, in accordance with an exampleimplementation.

FIG. 7 and FIG. 8 illustrate some example control plane protocols thatmay be implemented to transmit and/or relay information for use indetermining a state of proximity between two or more mobile devices, inaccordance with an example implementation.

FIG. 9 and FIG. 10 illustrate some example user plane protocols that maybe implemented to transmit and/or relay information for use indetermining a state of proximity or supporting proximity servicesbetween two or more mobile devices, in accordance with an exampleimplementation.

FIG. 11 illustrates example combined protocols that may be implementedto transmit and/or relay information for use in determining a state ofproximity or supporting proximity services between two or more mobiledevices, in accordance with an example implementation.

FIG. 12 and FIG. 13 illustrate some example protocols that may beimplemented to transmit, receive and/or relay information betweenapplications in two or more mobile devices, in accordance with anexample implementation.

FIG. 14, FIG. 15 and FIG. 16 are schematic block diagrams illustratingcertain example arrangements to support a network proximity server, inaccordance with an example implementation.

FIG. 17 is a schematic block diagram illustrating certain features of anexample mobile device that may be used to determine or assist indetermining a state of proximity between two or more mobile devices, inaccordance with an example implementation.

FIG. 18 is a schematic block diagram illustrating certain features of anexample electronic device that may be used to determine or assist indetermining a state of proximity between two or more mobile devices, inaccordance with an example implementation.

FIG. 19A and FIG. 19B are flow diagrams illustrating example processesthat may be implemented within one or more computing devices to supportproximity services, in accordance with an example implementation.

FIG. 20 is a flow diagram illustrating an example process that may beimplemented to support all or part of a general broadcast and relayingmethod among terminals, e.g., without network support, in accordancewith an example implementation.

DETAILED DESCRIPTION

The following terms and abbreviations may apply to the description anddrawings:

-   -   3GPP: 3^(rd) Generation Partnership Project    -   AP: Access Point    -   API: Application Programming Interface    -   App: Application (software or firmware entity)    -   Appln: Application (protocol or interface)    -   CP: Control Plane    -   CSCF: Call Session Control Function    -   D2D: Device to Device (refers to direct communication between 2        devices)    -   DHCP: Dynamic Host Configuration Protocol    -   EPC: Evolved Packet Core (for LTE)    -   eNB: evolved Node B (eNodeB)    -   E-SMLC: Enhanced Serving Mobile Location Center    -   Expression: A piece of data (e.g. 128 bit string) that encodes        the identity of a service performed for 2 or more UEs in        proximity to one another.    -   FQDN: Fully Qualified Domain Name    -   GMLC: Gateway Mobile Location Center    -   GTP-U: General Packet Radio Service (GPRS) Tunneling        Protocol-User Plane    -   HeNB: Home eNB    -   HSS: Home Subscriber Service    -   IETF: Internet Engineering Task Force    -   IM: Instant Message    -   IMS: IP Multimedia Subsystem    -   IMSI: International Mobile Subscriber Identity    -   IP: Internet Protocol    -   L1/L2/L3: Level 1/Level 2/Level 3    -   LTE: Long Term Evolution    -   LTE-D: LTE Direct (LTE version of D2D in which 2 UEs communicate        directly via LTE and not via a network)    -   LRF: Location Retrieval Function    -   MAC: Media Access Control    -   MME: Mobility Management Entity    -   MSISDN: Mobile Station International Subscriber Directory Number    -   NAS: Non-Access Stratum    -   P2P: Peer to Peer    -   P-CSCF Proxy CSCF    -   PDCP: Packet Data Convergence Protocol    -   PDG: Packet Data Network Gateway    -   PDP: Proximity Discovery Protocol    -   PDU: Protocol Data Unit    -   ProSe: Proximity Services    -   PS-AP: Proximity Services Application Protocol    -   RFC: Request for Comments    -   RLC: Radio Link Control    -   RRC: Radio Resource Control    -   RTT: Round Trip Time    -   S1-AP: S1 Application Protocol    -   S-CSCF: Serving CSCF    -   SCTP: Stream Control Transmission Protocol    -   SGW: Serving Gateway    -   SIB: System Information Block    -   SIP: Session Initiation Protocol    -   SLP: SUPL Location Platform    -   SUPL: Secure User Plane Location    -   TA: Tracking Area    -   TCP: Transmission Control Protocol    -   TLS: Transport Layer Security    -   TMSI: Temporary Mobile Subscriber Identity    -   TS: Technical Specification    -   UDP: User Datagram Protocol    -   UE: User Equipment (e.g., a mobile device/station/terminal)    -   UP: User Plane    -   URI: Uniform Resource Identifier    -   URL: Uniform Resource Locator    -   WiFi-D: WiFi Direct (in which two UEs communicate directly using        IEEE 802.11 WiFi signaling)

In the following description, the terms terminal, device, mobileterminal, mobile device, mobile station, station, user equipment (UE)are used interchangeably to refer to any wireless capable device that ismobile or potentially mobile such as a cellphone, smartphone, laptop orPDA. Further, the description below commonly assumes an LTE networkand/or LTE signaling for use and support of proximity services althoughthe methods described below may apply to other types of network andradio signaling in addition to LTE—e.g. may apply to networks and radiosignaling that use WCDMA, GSM, cdma2000, WiFi, WiMax and other radiotechnologies. In any context below where a particular type of network orparticular radio signaling is not specified explicitly or implicitly,the use of an LTE network or LTE signaling is intended at a minimum.

Wireless communication networks enable communication between two or moremobile wireless terminals and/or between any wireless terminal and oneor more fixed entities such as a network server no matter where eachwireless terminal may be located provided each terminal is in wirelesscoverage of some wireless network that can interconnect to othernetworks (e.g. via the Internet) and each terminal supports at least oneparticular type of wireless communication supported by the network it iscoverage with. Many different services (e.g. voice calls, data calls,Email, IM, texting) may then be provided to each wireless terminaland/or to the user of each wireless terminal and/or to applications oneach wireless terminal based on this communications capability. In somecases, additional services may be provided to two or more terminals thatare in proximity to one another (e.g. within 500 meters of one another)based on a higher level of interest in or a higher priority for suchservices or an improved capability to provide such services in thecontext of this proximity. As an example, two friends or colleagues mayhave a higher interest in mutual communication when in proximity to oneanother; two public safety responders may have higher priority toestablish communication when nearby to one another; and two terminalsmay be able to employ direct terminal to terminal communication withoutburdening a network when nearby to one another. For such reasons, it maybe beneficial for a network and/or for a terminal to determine when theterminal is within proximity to one or more other terminals. The processof determining whether two terminals are within proximity to one anothermay be referred to as “discovery” and the process may be performed byone or both terminals, or by a network with which either terminal is incommunication or by both a network and by one or both terminals.

Discovery or proximity may be based on the geographic location of eachterminal with proximity being discovered when two terminals are withinsome maximum distance of one another (e.g. 500 meters). Discovery ofproximity may instead be based on the ability of one terminal todirectly receive signals transmitted by another terminal—for example toreceive signals whose strength exceeds some minimum threshold. Each typeof discovery may require the expenditure of significant time andresources by a network and/or by the respective terminals—e.g. time andresources to periodically measure and compare the geographic locationsof the terminals or time and resources to transmit from a first terminaland receive by a second terminal signals distinct to the first terminal.The expenditure of such time and resources may be multiplied many foldwhen repeated for combinations of different pairs of terminals whoseproximity may be of interest. Therefore, methods to enable discovery ofproximity using fewer resources and less time may be of value. A furtherproblem with discovering proximity and taking suitable actions whenproximity is discovered (such as providing an indication of proximity tothe respective users or to applications on each terminal) is that theduration of proximity may be short lived and any delay in discoveringand reporting proximity may reduce the duration for which proximity hasbeen reported to a low value or even zero. Thus. For example, notifyinga pair of users in a shopping mall of their current proximity in orderto allow the users to arrange an impromptu rendezvous may be seriouslyimpaired if the notification occurs just as the reported proximity isabout to end. Therefore, methods to discover the occurrence of proximitywith little or no delay may also be of value.

In one implementation, the imminent geographic proximity of two or moreterminals may be predicted in advance based on the probable futurelocations of the terminals. The probable future location of any terminalmay be determined by extrapolating the current and past location andmotion of the terminal to predict its location (or an area or volumewithin which it should be located) at some future time. The probablyfuture location of a terminal may also be determined based on any knownhistoric behavior of the terminal (or more precisely of the user of theterminal) that has occurred in association with the current location ofthe terminal and/or in association with the current day and time.Examples of such behavior based location prediction may include (i) auser who is known to typically be at home, in a restaurant or at aworkplace at certain times and on certain days; (ii) a user whohabitually walks around a shopping mall after driving into and parkingnear a main entrance to the shopping mall; (iii) a user who takes adaily walk or daily jog at a certain time each day and using one of asmall number of different routes which may be distinguished by theuser's heading and location soon after starting; and (iv) a user whovisits a certain friend or relative by traveling there from home or froma workplace on certain days and/or at certain times using the same routefor travel each time.

In one implementation, a UE or a network server may predict a form ofgeographic location based on the UE's current location, speed andheading plus recent movement and/or historical location history. Here,such a UE or server may predict an occurrence of geographic proximity toanother UE before it occurs—giving UE users and UE applications moretime to react. In an alternative implementation, imminent geographicproximity may be predicted, at least in part, based on detection of twoUEs being in the same venue (e.g., a shopping mall, building, conventioncenter, railway or bus station or an airport) even if the geographicalseparation of the two UEs currently exceeds a particular threshold rangedefining proximity.

Discovery of proximity between two devices, whether based on an abilityto communicate directly between the devices (e.g., using LTE-D) or basedon geographic location and geographic separation, is likely to be aresource intensive process for UEs and/or networks. This may wellincrease capital and operating costs for network operators and/or impairbattery life and service provision for UEs. In addition, this may impairthe effectiveness of proximity support—e.g. if there are delays indiscovering whether two UEs are in proximity as a result of the limitedresources available for this.

In one implementation, a condition of “near proximity” may indicate acondition in which two UEs are close to one another but not close enoughto qualify for being in actual proximity. As an example, if actualproximity is defined as having a maximum separation of 2000 meters, nearproximity may be defined for a separation of between 2000 and 5000meters. A benefit of discovering near proximity may be that it would notneed to be determined very exactly—allowing coarse but resourceefficient methods to be used for support (e.g. methods that use fewernetwork and/or UE resources but are not able to determine a state ofproximity very accurately). Moreover, near proximity need not bereported to applications or users, but only maintained by networkservers and/or by some common proximity process or proximity engine ineach UE. Once near proximity has been discovered by coarse but efficientmeans, more accurate but less resource efficient methods can be used todiscover actual proximity for those UEs already discovered to be in nearproximity. Because the number of UEs in near proximity to one anotherfor any proximity service of interest to particular users and/or toparticular applications may comprise only a small fraction of any totalnumber of UEs that are potentially in actual proximity to one another inany area or region, using less efficient methods for determining actualproximity may not consume so many resources as when the same lessefficient methods are applied to all UEs without any initialprecondition. In addition, determining near proximity prior todiscovering actual proximity may reduce a delay for discovering actualproximity. Accordingly, near proximity may also be used to efficientlysupport discovery of proximity between UEs served by different networks.

In certain implementations, as shown in FIG. 1, a UE 100 may receive oracquire satellite positioning system (SPS) signals 159 from SPSsatellites 160. In some implementations, SPS satellites 160 may be fromone global navigation satellite system (GNSS), such as the GPS orGalileo satellite systems. In other implementations, the SPS Satellitesmay be from multiple GNSS such as, but not limited to, GPS, Galileo,Glonass, or Beidou (Compass) satellite systems. In otherimplementations, SPS satellites may be from any one of several regionalnavigation satellite systems (RNSS) such as, for example, Wide AreaAugmentation System (WAAS), European Geostationary Navigation OverlayService (EGNOS), Quasi-Zenith Satellite System (QZSS), just to name afew examples.

In addition, UE 100 may transmit radio signals to, and receive radiosignals from, a wireless communication network. In one example, UE 100may communicate with a cellular communication network by transmittingwireless signals to, or receiving wireless signals from, base stationtransceiver 110 over wireless communication link 123. Similarly, UE 100may transmit wireless signals to, or receive wireless signals from localtransceiver 115 over wireless communication link 125.

In a particular implementation, local transceiver 115 may be configuredto communicate with UE 100 at a shorter range over wirelesscommunication link 125 than at a range enabled by base stationtransceiver 110 over wireless communication link 123. For example, localtransceiver 115 may be positioned in an indoor environment. Localtransceiver 115 may provide access to a wireless local area network(WLAN, e.g., IEEE Std. 802.11 network) or wireless personal area network(WPAN, e.g., Bluetooth network). In another example implementation,local transceiver 115 may comprise a femto cell transceiver capable offacilitating communication on link 125 according to a cellularcommunication protocol. Of course it should be understood that these aremerely examples of networks that may communicate with a UE over awireless link, and claimed subject matter is not limited in thisrespect.

In a particular implementation, base station transceiver 110 and localtransceiver 115 may communicate with servers 140, 150 and/or 155 over anetwork 130 through links 145. Here, network 130 may comprise anycombination of wired or wireless links. In a particular implementation,network 130 may comprise Internet Protocol (IP) infrastructure capableof facilitating communication between UE 100 and servers 140, 150 or 155through local transceiver 115 or base station transceiver 110. Inanother implementation, network 130 may comprise cellular communicationnetwork infrastructure such as, for example, a base station controlleror master switching center (not shown) to facilitate mobile cellularcommunication with UE 100.

In particular implementations, and as discussed below, UE 100 may havecircuitry and processing resources capable of computing a position fixor estimated location of UE 100. For example, UE 100 may compute aposition fix based, at least in part, on pseudorange measurements tofour or more SPS satellites 160. Here, UE 100 may compute suchpseudorange measurements based, at least in part, on pseudonoise codephase detections in signals 159 acquired from four or more SPSsatellites 160. In particular implementations, UE 100 may receive fromserver 140, 150 or 155 positioning assistance data to aid in theacquisition of signals 159 transmitted by SPS satellites 160 including,for example, almanac, ephemeris data, Doppler search windows, just toname a few examples.

In other implementations, UE 100 may obtain a position fix by processingsignals received from terrestrial transmitters fixed at known locations(e.g., such as base station transceiver 110) using any one of severaltechniques such as, for example, advanced forward trilateration (AFLT)and/or observed time difference of arrival (OTDOA). In these particulartechniques, a range from UE 100 may be measured to three or more of suchterrestrial transmitters fixed at known locations based, at least inpart, on pilot signals transmitted by the transmitters fixed at knownlocations and received at UE 100. Alternatively, in otherimplementations, a difference in range between UE 100 and a pair of basestation transceivers 110 may be obtained from a measurement by UE 100 ofthe difference in transmission timing between the pair of transceiversas seen at the location of UE 100. The difference in range between UE100 and two or more different pairs of transceivers may be used toestimate a location of UE 100 by means of trilateration. Here, servers140, 150 or 155 may be capable of providing positioning assistance datato UE 100 including, for example, locations and identities ofterrestrial transmitters to facilitate positioning techniques such asAFLT and OTDOA. For example, servers 140, 150 or 155 may include a basestation almanac (BSA) which indicates locations and identities ofcellular base stations in a particular region or regions. In someimplementations, UE 100 may both measure and determine its estimatedlocation whereas in other implementations, UE 100 may perform locationmeasurements but return the results of the measurements to a server(e.g. server 140, 150 or 155) for computation of a location for UE 100.In some implementations, communication between UE 100 and one or more ofservers 140, 150 and 155 to enable UE 100 to perform locationmeasurements and enable UE 100 or one of servers 140, 150 or 155 todetermine a location for UE 100 may be according to a control planelocation solution such as solutions defined by the 3^(rd) GenerationPartnership Project (3GPP) and by the 3^(rd) Generation PartnershipProject 2 (3GPP2). In other implementations, this communication betweenUE 100 and servers 140, 150 and 155 may be according to a user planelocation solution such as the Secure User Plane Location (SUPL) locationsolution defined by the Open Mobile Alliance (OMA).

In particular environments such as indoor environments or urban canyons,UE 100 may not be capable of acquiring signals 159 from a sufficientnumber of SPS satellites 160 or from a sufficient number of base stationtransceivers 110 whose location are known to perform AFLT or OTDOA tocompute a position fix. Alternatively, UE 100 may be capable ofcomputing a position fix based, at least in part, on signals acquiredfrom local transmitters (e.g., WLAN access points positioned at knownlocations). For example, UEs may obtain a position fix by measuringranges to three or more indoor terrestrial wireless access points whichare positioned at known locations. Such ranges may be measured, forexample, by obtaining a MAC ID address from signals received from suchaccess points and obtaining range measurements to the access points bymeasuring one or more characteristics of signals received from suchaccess points such as, for example, received signal strength (RSSI) orround trip time (RTT) for signal propagation. In alternativeimplementations, UE 100 may obtain an indoor position fix by applyingcharacteristics of acquired signals to a radio heatmap indicatingexpected RSSI and/or RTT signatures at particular locations in an indoorarea. In particular implementations, a radio heatmap may associateidentities of local transmitters (e.g., a MAC address which isdiscernible from a signal acquired from a local transmitter), expectedRSSI from signals transmitted by the identified local transmitters, anexpected RTT from the identified transmitters, and possibly standarddeviations from these expected RSSI or RTT. It should be understood,however, that these are merely examples of values that may be stored ina radio heatmap, and that claimed subject matter is not limited in thisrespect.

In particular implementations, UE 100 may receive positioning assistancedata for indoor positioning operations from servers 140, 150 or 155. Forexample, such positioning assistance data may include locations andidentities of transmitters positioned at known locations to enablemeasuring ranges or measuring differences in ranges to thesetransmitters based, at least in part, on a measured RSSI and/or RTTand/or transmission time difference of arrival, for example. Otherpositioning assistance data to aid indoor positioning operations mayinclude radio heatmaps, magnetic heatmaps, locations and identities oftransmitters, routeability graphs, just to name a few examples. Otherassistance data received by the UE may include, for example, local mapsof indoor areas for display or to aid in navigation. Such a map may beprovided to UE 100 as UE 100 enters a particular indoor area. Such a mapmay show indoor features such as doors, hallways, entry ways, walls,etc., points of interest such as bathrooms, pay phones, room names,stores, etc. By obtaining and displaying such a map, a UE may overlay acurrent location of the UE (and user) over the displayed map to providethe user with additional context.

In some implementations a pair of UEs (e.g., UE 100 and UE 100′) in FIG.1 may be in proximity to one another. The proximity may be determined byestimating the geographic location of each UE using for example themethods described previously and determining that the distance betweenthe two geographic locations is less than some maximum threshold. Theproximity may alternatively be determined from the ability of one UE toreceive a signal 101 transmitted by the other UE with a strength greaterthan some minimum threshold. The proximity may also be determined fromthe ability of one UE to obtain an RTT to the other UE by directlyexchanging signals with the other UE (e.g. using LTE-D or WiFi-D) andmeasuring the propagation time and subsequently determining that thedistance between the two UEs based on the RTT is less than some maximumthreshold. The discovery of proximity may occur in one or both UEs ormay be performed by a serving network for the UEs—e.g. network 130—or bya server attached to or reachable from network 130 such as server 140,150 or 155. The discovery may also involve interaction between the UEs,the network 130 and/or servers 140, 150 and/or 155. In some otherimplementations, the UEs may not be currently in proximity but may be inproximity at a later time with such later proximity predicted oranticipated by the UEs, network 130 and/or by servers 140, 150 and/or155. The prediction or anticipation of future proximity may be based, atleast in part, on one or more of: (i) current location, speed andheading of one or both UEs; (ii) previous location, speed and heading ofone or both UEs; (iii) previous user location history for one or bothUEs; (iv) determination that both UEs are in the same venue; and (v)determination that UEs are in near proximity to one another.

Proximity Services, Discovery and Expressions

In accordance with certain aspects, various example techniques areprovided herein which may be implemented to provide support of discoveryfor proximity services (ProSe) and/or other like services, in general;and, in certain instances, support of communication for individualproximity services using LTE-D and/or the like.

Some of these example techniques are based on geographic proximity(e.g., related to geographic distance between nearby devices); and, incertain instances, ProSe support using LTE-D where network support maybe unavailable.

As used herein, a “proximity service” may be any service that isprovided to the user of a first device and/or to an application runningon the first device that is contingent on the first device being inproximity to one or more other devices that support or are associatedwith the same service. A proximity service may just constitute anotification to the user and/or to the application that the first deviceis in proximity to one or more other devices supporting or associatedwith this service and may, in this case, provide some identification foreach of these other devices—e.g. a phone number, a subscriber or useridentity, a device identity—as well as information for the other devicessuch as the location of each device relative to the first device. Aproximity service may instead or in addition provide communicationcapability with the other devices (which may require permission from therespective users before being setup) in the form of voice, video, IMand/or text to name a few examples. A proximity service may also enhancesome existing service—for example by replacing some existingcommunication channel between the first device and one or more of theother devices that is supported by a network with an equivalentcommunication channel that employs direct device to device communication(e.g. LTE-D) and does not reply on support by a network. Such anenhanced service may improve communication quality, reduce communicationdelay, reduce network operator billing and/or reduce usage of networkresources. A proximity service may be associated with a particularapplication on a device (e.g. may provide enhanced service specificallyfor this application). Discovering whether two or more devices are inproximity may then be performed in association with the particularservice that can be enhanced or enabled by the resulting proximity. Inparticular, it may then be necessary to first determine whether two ormore devices are capable of supporting and have an interest insupporting the same proximity service prior to discovering whether theyare in proximity since if the devices have no proximity service incommon, there would be no benefit in their being in proximity.Furthermore, some proximity services may be restricted to particularsets of devices or users (e.g., a particular set of friends or theemployees of a particular company or the customers of a particularshopping chain) or particular types of devices (e.g. a particular brandof phone) or devices or users with some other common characteristic(e.g. an interest in stamp collecting). In still other cases, proximityservices may be restricted to asymmetric groupings of devices—e.g.devices belonging to shoppers in a shopping mall and to stores in theshopping mall—where proximity is only of interest when it occurs betweendevices belonging to different categories (e.g. shoppers and stores inthe previous example). In order to identify proximity services and helpdetermine whether two or more devices have a mutual interest in the sameproximity service, each proximity service may be assigned an identifierwhich may employ a particular sequence of bits called an “expression”.

As used herein, an expression may provide a globally uniqueidentification for a particular proximity service performed on behalf ofa particular set of users or applications. In certain instances, anexpression may comprise a limited number of bits (e.g. 128 bits) thatmay be broadcast by UEs and base stations without significant impact onbandwidth usage. A UE that receives an expression broadcast by anotherUE may then be able to determine whether the expression relates to aproximity service of common interest to both UEs and whether the otherUE is also in proximity.

In an example implementation, UEs may broadcast one or more expressionsin an attempt to discover and be discovered by one or more other UEs.Here, for example, in certain instances, two UEs associated with (e.g.that each broadcast) the same expression may be assumed to participatein the same proximity service. In order for the proximity service to beprovided, the two UEs may first need to be within a certain proximitythreshold of one another (e.g. be in direct radio contact or have acertain maximum geographic separation). Determining that the two UEssupport the same proximity service and are in proximity may be referredto as ‘discovery’ or ‘discovery of proximity’ or ‘determining a state ofproximity’.

In certain example implementations, generic expressions may be used andwhich may be structured in a standardized manner in order to categorizeproximity services globally (e.g. by partitioning an expression intoseparate fields each identifying one category of proximity service).

In some example implementations, application specific expressions (IDs)may be used and which may be assigned by particular providers ofproximity services and/or the like, and which in certain instances maynot conform to any global scheme, etc.

Various techniques may be provided for use in obtaining and/or usingexpressions. By way of example, in certain instances, a specificproximity service (or type of proximity support) may be associated witha globally unique expression. In certain example implementations, Appson a UE that support or make use of different proximity services maydetermine the expression that has been assigned (e.g. by a globalstandard or by a provider of proximity services) for each supportedproximity service via (i) interaction with the user of the UE or (ii)interaction with some proximity related server or (iii) hard coding orotherwise providing the expression as part of the App.

In an example implementation, a user may interact with an App and aserver and/or the like to select proximity support associated withfinding a nearby restaurant, gas station, shop, etc. An associatedexpression or expressions may be provided by the server to the App(e.g., possibly with some limited lifetime after which the App may needto re-invoke the server to validate current expressions and/or possiblyobtain new expressions). The App may then invoke proximity services(e.g., via interaction with a proximity engine on the UE and/or a remoteproximity server in the serving wireless network). The App may providethe expressions obtained previously from the server to a local proximityengine and/or to a remote proximity server together with proximityrelated parameters (e.g., a maximum distance to define geographicproximity). The proximity engine and/or remote proximity server may theninvoke standardized proximity support (e.g. as described later herein)to discover whether other UEs sharing the same proximity service(s) arein proximity and report back the identities and possibly the locationsof any such UEs that share the same expressions that were found to be inproximity.

In certain example implementations, one or more operator centricexpressions may be utilized. For example, it may be worthwhile to vestsignificant control over one or more expressions in wireless operatorsin order to bootstrap deployment of a workable system to supportproximity services and discovery of proximity with low up frontdeployment and maintenance costs. To enable this, one or more genericexpressions may, for example, be simplified and/or standardized, e.g.,to support specific application specific IDs, etc. In certain instances,such a generic part (including possibly an operator ID) may bestandardized to enable operator support of proximity category toexpression mappings, e.g., down to a certain level. In certaininstances, an application part may be defined by each operator and/or bythe operators' clients. By way of a non-limiting example referred toherein as “example A”, a possible standard may support different levels,such as, e.g., Level 1: proximity category (e.g. Retail, Onlineservice); Level 2: proximity sub-category (e.g. Friend Finder); Level 3:Operator (which may instead be defined at level 1 and include country orregion); Levels 4+: either standardized or operator defined. Theresulting operator associated expressions may be more like otherwireless network IDs, e.g. IMSI, MSISDN, public SIP URI, etc.

In certain example implementations, support of one or more expressionsmay be supported by multiple operators. For example, in certaininstances, some clients (e.g., a search engine, a social network site, adepartment store, etc.) may obtain a single expression from just oneoperator for a particular proximity service. Such an implementation,may, for example, make use of support for roaming where an operator Xprovides support for proximity services for expressions assigned byanother operator Y (e.g., and may bill operator Y for doing this).

In other instances, some clients may obtain a different expression fromeach of a number of different operators for the same proximity service.With this option, different expressions, or “aliases” may arise fromdifferent operators which may identify the same proximity service.Operator servers may, for example, store aliases assigned by otheroperators (assuming these are provided by the client Apps), e.g., toenable proximity discovery between UEs accessing different networks, andprovide additional mapping support between proximity service names andexpressions. In certain instances, client UEs and Apps may also be madeaware of such aliases, e.g., in order to use the correct expression(s)in a serving network and to recognize expressions of interest fordiscovery. In a particular implementation, an expression (or expressionset) may serve as a default in a network whose operator may not haveassigned any expressions of its own to a particular client.

In accordance with certain aspects, techniques provided herein maysupport different business models and/or relationships. For example, incertain instances, operators may own an expression space assigned tothem in a standard (e.g. Levels 4+ in the earlier example A), and maysell or lease all or possibly subsets of their expression space (eithersingle expressions or a set of expressions) to their clients. By way ofan example, a telecommunications company may be assigned an expressionspace E (worldwide or country/region specific). As such, thetelecommunications company may sell or lease subsets E1, E2, E3 of E toa social network provider, a search engine provider, a news agency,respectively. Having purchased or leased subset E1, the social networkprovider may itself, in certain instances provide, sell or lease subsetsE1-1, E1-2, E1-3, . . . of subset E1 to one or more App providers,users, user groups, etc.

In certain example implementations, one or more clients may be providedan opportunity to buy or lease expressions (e.g. as exemplified above)via online means, by telephone or through personal negotiation, etc.Operators may, for example, provide LTE-D support and/or the like forthe expressions and expression subsets they sell or lease (e.g., as partof the sale or lease). As such, there may be no need initially for acomplex global system of servers to assign, translate and supportexpressions. Instead each operator may, for example, provide its ownserver to support mappings, e.g., for its own expressions (and aliases).

A client who obtains sets or subsets of expressions by the above meansmay provide services to its own clients based on the expressionspurchased or leased from operators. By way of a first example, a socialnetwork service and/or the like may enable users to setup, subscribe toand withdraw from user groups associated with a friend finder serviceand/or the like. For example, assume that a user group A currentlycomprises users A1, A2 and A3, and a user group B currently comprisesusers B1, B2 and B3. As such, a globally unique expression may beassigned to each group, e.g., Group A may be assigned expression EA, andGroup B may be assigned expression EB. In order to discover one another,users A1, A2 and A3 may then broadcast their group expression (e.g.,expression EA), and users B1, B2 and B3 may broadcast their groupexpression (e.g., expression EB). In a second example, a social networkservice and/or the like may enable users having a common interest (e.g.,for gaming, antiques, art, motor bikes) to possibly set up, and/orsubscribe to and withdraw from user groups associated with the commoninterest. Such user groups may then be assigned a group expression forbroadcast during discovery. However, it may be beneficial for suchdiscovery to be more selective than it might be with regard to a friendfinder service, e.g., allowing users to hold back from being discovered.

In certain example implementations, it may be beneficial to provisionone or more virtual UEs and/or the like. A virtual UE may be a networksupported placeholder for a real UE without the need for actual physicaldeployment of a real UE. A virtual UE may be supported as logical entityin a network server or web server and may be assigned certaincharacteristics associated with a real UE and be enabled by the serverto perform certain services and engage in certain communication normallysupported by a real UE. Thus, a virtual UE may be assigned a specific(e.g. fixed) location, a specific UE identity and may be enabled tosupport certain proximity services. For fixed subscribers (e.g. a coffeeshop, a hotel, an airport) with an interest in supporting certainproximity services, there may then be no need to deploy real mobile (orfixed) wireless terminals, which may simplify deployment by these typesof clients by instead deploying one or more virtual UEs able to supportthe same proximity services. Network operators may then configureinformation about such virtual UEs and the proximity services they eachsupport (e.g., expression(s), name, location, associated networkcell(s), other meta-data, attributes, IP address, URL(s)) in one or morewebsites and/or the like. In certain instances, proximity to real UEsmay still be determined (e.g. by a network proximity server with accessto configured information for virtual UEs) based on the actual locationsof the real UEs and the configured locations for the virtual UEs.Discovery methods that rely on comparing the locations of UEs may thusbe usable if the locations of the virtual UEs are provided to real UEsby the network (e.g. via broadcast from base stations such as eNBs or bya proximity server) or if comparison of locations is performed in anetwork server with access to both the actual locations of real UEs andthe configured locations of virtual UEs. One exception to discovery maybe radio based D2D discovery which may not be possible since virtual UEswill not be able to send and receive signals to and from real UEs.Should proximity between a virtual UE and real UE be discovered (e.g.,by the network or by the real UE), the network may provide associatedmeta-data including IP addresses and/or website URLs to real UEsdiscovered to be in proximity to virtual UEs. In certain instances, Appsor users for the real UEs may then interact with the discovered virtualUEs using the provided IP address and/or URLs. The interaction mayappear to an App or user for a real UE as being the same as interactionwith another real UE but may in fact be supported via interaction with aserver or website acting on behalf of the virtual UE. Thus, for example,in certain instances an App or user for a real UE may not need to beaware whether another discovered UE is real or virtual.

Discovery and Prediction of Proximity

In accordance with certain aspects, the techniques provided herein mayenable prediction of a geographic proximity between two or more UEs. Inone example, a geographic proximity may be predicted for two UEs, atleast in part, using current geographic locations and possibly currentvelocities of the two UEs to determine whether they are or may later bein proximity. Here, for example, two UEs designated UE A and UE B may bedetermined to be in geographic proximity if currently within 1000 metersof each other. In another example, UEs A and B may be determined to bein geographic proximity if currently within 1000 meters of each otherand provided each UE is traveling at less than 5 meters/second. Theconditions for determining geographic proximity may be defined by anetwork operator, a wireless standard or participating Apps andusers—e.g. an App that supports or can be provided with a particularproximity service may define the conditions for its UE being inproximity to some other UE for this particular proximity service. Inthat case, different conditions may be defined in which geographicdistance may be augmented with other conditions such as the currentspeed of each UE. Speed may be significant if there is no interest (e.g.by a participating UE) in discovering proximity to a fast moving UE thatmay not stay very long in proximity or whose user may not be in aposition to communicate or affect a rendezvous with the user of anotherUE. Of course, these are also just a few examples and subject matter isnot intended to be necessarily so limited.

In certain instances, a predicted geographic proximity may be based, atleast in part, on one or more probable future locations (and possiblyfuture velocities) of two UEs to determine whether proximity is likelyto occur within some time span (e.g., within the next hour, etc.). Aprobable future location may be determined in a variety of ways. Forexample, in certain instances a probable future location may bedetermined, at least in part, by extrapolating current and past motionof a UE to predict its location (or area or volume within which itshould be located) at some future time. In another example, in certaininstances a probable future location may be determined, at least inpart, based on known past behavior of the user, e.g., in associationwith a current location, a current day and time, etc. For example, knownpast behavior of a user may indicate that the user is likely to be athome, in a restaurant, at a shopping mall or at a workplace at certaintimes and on certain days. For example, known past behavior of a usermay indicate that the user is likely to exhibit certain habits whilevisiting a certain location such as a shopping mall, park or sportsarena, e.g., possibly after having driven into an adjacent parking lotor parking garage and parked near a particular entrance, etc. In anotherexample, known past behavior of a user (e.g. as implied by a locationhistory for the UE that may be stored in the UE or in a network locationserver or network Proximity server) may indicate that the user is likelyto move some significant distance away from and then back to a certainlocation (e.g. in order to take a daily walk or jog) at a certain timeeach day, e.g., possibly along one of a small number of different routeswhich may be distinguished by the user's heading and location soon afterstarting. In still another example, known past behavior of the user mayindicate that the user is likely to move from location to another (e.g.in order commute to or from work or to visit a friend or relative fromthe user's home or workplace) on certain days and/or at certain times,e.g., possibly using the same route and/or traveling at about the samespeed each time. Again, as with all of the examples herein, claimedsubject matter is not intended to be necessarily so limited. Based onone or more of the current and past location and velocity of each UE andany known past location history of each UE, either of the UEs or anetwork location server may be able to predict that the two UEs may bein proximity after some time interval with some probability and may beable to estimate the time interval and the probability (e.g. at leastcoarsely). If the time interval is less than (or falls below) somethreshold and/or if the probability is greater than (or exceeds) somethreshold, an application on each UE or the user of each UE may beinformed that both UEs are or may later be in proximity.

FIG. 2 shows an example arrangement 200 of two terminals comprisingterminal A 206 and terminal B 208. The current distance 210 betweenterminals A and B may be too great to consider terminals A and B asbeing currently in proximity to one another. However, it may be possiblefor terminal A and/or terminal B or a serving network (e.g. network 130)or network server (e.g. server 140, 150 or 155) to predict thatterminals A and B may later be in proximity based on their probablefuture locations. For example, area 202 may represent an area withinwhich terminal A 206 may be predicted to be within at some future time(e.g. 30 minutes later) based on such factors as the current location ofterminal A, the current velocity of terminal A, the recent movementhistory of terminal A and/or known past behavior of terminal A when ator nearby to its current location and/or at the current time on previousdays and/or on the same day of the week on previous weeks. Similarly,area 204 may represent an area within which terminal B 208 may bepredicted to be within at the same future time (e.g. 30 minutes later)based on the same or similar factors applicable to terminal B to thosementioned above for terminal A. The two predicted areas 202 and 204 mayoverlap as illustrated in FIG. 2 or may not overlap but be close to oneanother (not shown in FIG. 2). In particular, there may be manylocations in area 202 that are in proximity to many other locations inarea 204 due to being within a required maximum distance for consideringtwo terminals to be in proximity. Accordingly, it may be predicted thatterminals A and B may be in proximity to one another at a later time(e.g. 30 minutes later). While the prediction may not associate aprobability of 100% of proximity occurring, it may be possible todetermine a lower probability for the occurrence of proximity (e.g.based on the extent to which areas 202 and 204 overlap or the meanproportion of area 204 that is in proximity to any random location inarea 202). If this lower probability is not insignificant (e.g. is 20%or higher), a state of proximity may be predicted (e.g. by terminal A,terminal B, a serving network or a network server) for a later time(such as 30 minutes later). Furthermore, when proximity is predicted tooccur at some future time (e.g. 30 minutes later) with some probability,the proximity (if it occurs) may actually begin to occur at an earlieror later time than that predicted meaning that prediction may at bestindicate a likelihood of proximity occurring but not an exact time whenit will occur. The predicted proximity may then be indicated at thecurrent time (e.g. 30 minutes before the proximity may occur) to one ormore applications on terminals A and B and/or to the users of terminalsA and B in the case that applications or users have an interest inreceiving or performing some common proximity service. The indication ofpredicted proximity may also include the fact that proximity ispredicted and not current or may not include this information tosimplify interaction with applications and users and reduce thecomplexity of any response from applications or users.

For some proximity services (e.g. friend/relative finder) it may be anadvantage to inform one or both terminals of imminent proximity beforeit actually occurs, e.g., so that one or both users may adjust theirmovements to meet up, etc. Proximity may thus be indicated, based on aprediction, before it actually occurs. A prediction may make use of thelocation history of each terminal, which in some implementations may bestored only in the terminal (e.g., for privacy) or in otherimplementations may be stored in a network server with an understandingthat the location history is generally or only to be used to provide orenhance service provision to the terminal's user. In certain instances,to make use of such techniques, terminals may be informed of thelocations of other terminals, possibly even when outside normalproximity bounds to allow any terminal to compare both its currentlocation and predicted future locations with the current locations ofother terminals and determine whether proximity may occur in the future.

It should be noted that the type of prediction described in associationwith arrangement 200 in FIG. 2 may only be possible in an optimum mannerin a network or network server. If prediction is performed by aterminal—e.g. by terminal A 206 or terminal B 208 in FIG. 2—the terminalmay only be in possession of its own location history but not thelocation history of the other terminal for reasons of privacy. Thus, forexample, terminal A 206 may be able to determine the area 202 for itsown future location with some reliability but may only determine thearea 204 for the future location of terminal B 208 with lowerreliability due to basing this only on the current location (andpossibly current velocity) or terminal B but not any previous locationhistory for terminal B. However, even this more limited capability maybe useful—e.g. if the area 202 for the predicted future location ofterminal A overlaps the current location of terminal B, terminal A maypredict that proximity between terminals A and B will be possible.

FIG. 3 is an illustration showing yet another example arrangement 300wherein a state of proximity may be determined to exist between certainmobile devices (represented by terminals A 206 and B 208) based, atleast in part, on map and/or context consideration(s), in accordancewith an example implementation. For example, a venue based proximity maybe determined. Here, for example, area 302 may represent a common venuewithin which terminals A 206 and B 208 may both be determined to belocated. In certain instances, terminals that may be in the same venuemay be considered to be in proximity even though a current distance 210between them may be too large to justify a normal (e.g.,threshold-based) geographic proximity. Examples of venues may include: ashopping mall, a sports stadium, a convention center, a hospital, anairport, a railway station, an office building, a museum, a touristsite, etc. In certain instances, a venue may even be quite large, e.g.,a park or a national park, and/or the like.

In example arrangement 300, even though terminals A 206 and B 208 arecurrently too far apart to be considered to be within geographicproximity, their location in the same venue may justify alerting one orboth of the terminals to being in a venue based proximity.

Determining that a terminal is within a particular venue may be done bythe venue itself. For example: WiFi access points, base stations orfemtocells belonging to the venue may detect the presence of terminalswithin the venue (e.g. when a terminal attaches or registers forwireless service or simply transmits an identification such as WiFi MACaddress as part of normal wireless operation). Alternatively or inaddition, a location server belonging to the venue may periodicallyidentify and locate terminals as being within the venue using networkbased positioning with minimal terminal support and/or may locate aterminal (e.g. with terminal support) whenever an App on the terminal orthe user requests some service from the venue (such as directions or amap), In addition, terminals passing quickly through or past a venue(rather than staying within the venue) may be excluded by examiningrecent location and velocity history in which terminals only temporarilywithin the venue may be identified from a high sustained velocity or alocation history that only temporarily intersects the geographic area ofthe venue.

In certain implementations, a determination of venue based proximity maybe supported by the venue itself (e.g., by some server belonging to thevenue, etc.) if users and their associated proximity requirements areknown to the venue (e.g. via some previous registration of a terminalwith the venue). Alternatively, once terminals discover being in a venue(e.g. from information provided point to point or by broadcast by thevenue), the venue information may be added to location information inthe terminal to enable proximity determination by a terminal or by someproximity supporting server in a serving wireless network.

Once two terminals A and B are discovered to be in the same venue—e.g.by the terminals or by a network proximity server—the users of theterminals and/or one or more applications on each terminal may benotified if the users or applications for both terminals support or havean interest in the same proximity service(s). The notification may justindicate that proximity was discovered or may provide an indication thatproximity was discovered due to being in the same venue. In the lattercase, the users or applications can be aware that the terminals (andusers) may not necessarily be sufficiently close to qualify for being innormal geographic proximity.

Near Proximity

In certain implementations, a distinction may be made between nearproximity and actual proximity. By way of example, FIG. 4 is anillustration showing an example arrangement 400 (not drawn to scale)wherein various states of proximity may be determined to exist betweencertain mobile devices, in accordance with an example implementation.Here, mobile devices are represented by terminals A, B, C, D, E, F, G,and H, each illustrated as being dispersed within arrangement 400 atdifferent locations. For example, terminals A, B and C are within afirst area 402 (e.g., a circle with a radius of 2 km, centered at thelocation of terminal A). For example, terminals D, E, F, and G arewithin a second area 404 (e.g., an annulus with a circular outer radiusof 5 km and a circular inner radius of 2 km, both centered at thelocation of terminal A). Additionally, terminal H is shown as beinglocated at a distance of 12 km from the location of terminal A outsideof both first area 402 and second area 404.

In certain instances, terminals are considered to be in near proximityif determined to be too far apart to qualify for actual proximity (e.g.,threshold based) but near enough together that actual proximity mayoccur after some short period of time (e.g. within the next hour). Incertain instances, being in near proximity may be associated with adistance threshold (e.g. the outer radius in FIG. 4) that exceeds adistance threshold for actual proximity (e.g. the inner radius in FIG.4). In certain instances, for terminals in near proximity, direct radiocontact and radio discovery may not be possible or may be possible butwith a signal level less than a required minimum threshold, however,e.g., due to relatively large separation distances. Likewise, in certaininstances a maximum threshold on distance to qualify for being ingeographic proximity may be exceeded. Arrangement 400 shows, forexample, that terminals B and C may be in actual geographic proximity toterminal A while located within first area 402 (e.g., applying athreshold distance/range of 0-2 km). Terminals D, E, F and G may be innear proximity to terminal A while located within second area 404 (e.g.,applying a threshold distance/range of 2-5 km). Terminal H may bedetermined to be in neither actual nor near proximity to terminal A(e.g., due to exceeding the example threshold distances/ranges). Ofcourse, these are just a few examples and subject matter is not intendedto be necessarily so limited.

In certain implementations, near proximity may not need to be accuratelydetermined because users and Apps may not be informed about it. Forexample, if near proximity has a maximum distance threshold of 5 km anda minimum distance threshold of 2 km as in the previous example, itcould suffice to determine near proximity when the distance was knownonly to be in the range 0-10 km. This means that approximate terminallocations may be used to discover near proximity, e.g., locationsdetermined from the terminal's current serving cell or current networkarea (such as a tracking area in the case of an LTE network or alocation area in the case of a WCDMA or GSM network) or from somepreviously determined (and possibly no longer current) location, speedand heading. In certain implementations, near proximity may be used toassist discovery of actual proximity, e.g., on a periodic or otherbasis.

In certain example implementations, a network server and/or terminal Amay periodically or at various times scan using a scan method M1 andscan rate (or scan frequency) R1 for other terminals to determine whichones may be in near proximity to the terminal A. In certain instances, anetwork server and/or terminal A may periodically scan the terminalsalready found to be in near proximity (and optionally already in actualproximity) to the terminal A, e.g., using a scan method M2 and scan rate(or scan frequency) R2 to determine which of these terminals may (or maystill) be in actual proximity to terminal A. The scan rates R1 and R2may correspond to the frequency with which scan methods M1 and M2 areused by a network server and/or terminal to determine a state of nearproximity and actual proximity, respectively, between a pair ofterminals.

By way of example, the scan method M1 may be simple and efficient andthe scan rate R1 may be low (e.g., one scan every 15 minutes). Scanmethod M1 may, for example, consider all terminals that use the sameproximity services as terminal A and that may be nearby to terminal A,e.g., which may (at times) comprise a large number of terminals. Anexample scan method M2 may be more complex, e.g., possibly more accurateand less efficient than method M1, and the scan rate R2 may berelatively higher (e.g., one scan every 5 minutes). Scan method M2 may,for example, consider terminals already discovered to be in nearproximity to terminal A (e.g., via scan method M1). As such, the numberof such terminals scanned by method M2 may be significantly reduced(e.g. much less than the number of terminals scanned by method M1) andmay even be zero at times. Since method M2 may scan a relatively smallernumber of terminals, it may be more complex than method M1 and hencepossibly more accurate without requiring significantly more processingand storage resources than method M1. By way of a further example,method M1 may consider or otherwise make use of information indicativeof a serving cell, a tracking area in the case of LTE, a previous(possibly no longer current) location estimate, visible WiFi APs, and/orthe like or some combination thereof. By way of example, method M2 mayadditionally or alternatively consider or otherwise make use ofinformation indicative of a current geographic location, measured RTTbetween 2 terminals, a direct radio detection, and/or the like or somecombination thereof. By way of example, method M1 may be similar to orthe same as method M2 but may use fewer resources than M2 due toemploying coarser location accuracy and/or lower scan rate R1.

In certain example implementations, a network proximity server may beused to discover proximity and near proximity between pairs ofterminals. The proximity server may exchange information with terminalsvia a control plane or user plane based solution. With a control planesolution, signaling to support discovery of proximity (e.g. signalingbetween the proximity server and any terminal and signaling between theproximity server and other network elements) may mainly make use ofexisting network interfaces and protocols. With a user plane solution,signaling between the proximity server and any terminal and possiblysignaling between the proximity server and other network elements may beconveyed as data by intermediate entities (e.g. using TCP/IP or UDP/IPprotocols). Additional aspects of proximity servers and control and userplane solutions are described later herein—e.g. in association withFIGS. 7, 9, 14, 15 and 16. When a control plane proximity solution isused by an LTE network, all or some of the following information may beused to maintain near proximity information for terminals in a proximityserver: (i) current tracking area of each UE when in idle mode as knownto the serving MME for the UE; (ii) current serving eNB of each UE whenin connected mode as known to the serving MME; (iii) proximity servicesused by (or of interest to) each UE—e.g. as denoted by a uniqueexpression assigned to each proximity service—and as provided by the UEto the MME (e.g. on network attachment) and/or as provided by the UE'sHSS to an MME when the UE attaches; and/or (iv) periodic locationestimates for a UE, provided by the UE (e.g. when a Tracking Updateoccurs) or obtained by the network (e.g. instigated by a serving MME ora proximity server).

In certain example implementations, if a network proximity server isused with a user plane proximity solution, UEs may periodically updatethe proximity server with the following: current serving or camped oncell ID; approximate or accurate UE location; and/or proximity servicesused by (or of interest to) each UE—e.g. as denoted by a uniqueexpression assigned to each proximity service.

In certain instances with either a control plane or user plane proximitysolution, a proximity server may use received information (e.g. asexemplified above) to create, update and maintain a list of otherterminals in near proximity to any particular target terminal, e.g., fora proximity service common to such terminals. By such means, a networkproximity server may establish and maintain a list of other terminalsthat are in near proximity to some other target terminal with respect toone or more or more proximity services of common interest to the targetterminal and the terminals in near proximity.

If discovery of actual geographic proximity is desired for some terminalA, a network proximity server may, for example, obtain accurate locationinformation to verify which terminals (that may have already beendiscovered to be in near proximity to the terminal A) may be in actualgeographic proximity to terminal A. In certain implementations,terminals may be located by a network (e.g. using SUPL or a controlplane location solution), e.g., on a periodic basis. In certainimplementations, terminals may be instructed to listen for otherterminals and measure and provide the RTT between them. The terminallocations and/or RTT values may be used to calculate the currentdistance between terminal A and each terminal that is in near proximityto terminal A in order to determine which terminals in near proximityare currently in actual proximity to the terminal A.

In certain example implementations, should actual radio proximity bedesired to be determined rather than geographic proximity, terminals innear proximity may be instructed to enter radio discovery mode, e.g., inwhich each terminal may periodically broadcast and/or listen forbroadcasts from other terminals. In certain instances, a server mayidentify or provide characteristics (e.g., signal characteristics) forthe other terminals (in near proximity to a terminal A) to any terminalA to possibly make listening by terminal A more efficient. In certaininstances, terminals may be switched out of radio discovery mode whennot needed (e.g. if there are no other terminals in near proximity) topossibly save on battery as well as radio and processing resources.

In certain example implementations, techniques may be implemented tosupport inter-network discovery of near proximity in which terminalsserved by different networks may be discovered to be in proximity. Forexample, in certain instances, terminals may be enabled to discoverterminals accessing other networks that share common proximity services,e.g., by extending some of the concepts described previously regardingnear proximity and actual proximity. Networks (e.g. network proximityservers belonging to different networks) may, for example, exchangeinformation regarding near proximity which may comprise: anidentification L of a location point or location area or volume whichmay be a coarse location; and/or an identification P of each proximityservice used by at least one terminal that may be present near or withinthe given location, area or volume L. In certain instances, anidentification L may refrain from referring to cells, network areas(e.g. LTE tracking areas), and/or the like, since such information maybe specific to a particular network and may be confidential and notknown to other networks. Instead, an identification L may, for example,be defined using standard location coordinates (e.g. lat/long) or usingsome agreed to set of geographic location areas common to two or morenetworks such as location areas defined by a grid system (e.g. arectangular grid made up of 200×200 meter cells where each cell has aunique label which is used to define L and is known to all participatingnetworks). A network (server) N1 may, for example, then transfer toanother network (server) N2 a list of locations L1, L2, L3 . . . and foreach location Li, may transfer a list of one or more proximity servicesPi1, Pi2, Pi3 . . . supported by terminals currently served by networkN1 that may be inside, at or nearby to location Li. A network (server)N2 may, for example, use received information from network N1 todetermine whether any of network N2's terminals that share the sameproximity service(s) (Pi1, Pi2 etc.) may be in proximity or nearproximity to terminals in network N1 As an example, network N2 mayassume near proximity for any proximity service Pm reported by networkN1 for any location (area or volume) Ln if one or more of network N2'sterminals subscribing to (or supporting or having an interest in) Pm maybe at, in or nearby to Ln since terminals from both networks N1 and N2with an interest in a common service Pm would then be in, at or nearbyto the same location Ln. The discovery of near proximity in this casemay just be limited to a knowledge by each network (or each networkproximity server) that for a certain coarse location L, some terminalsserved by the network at, in or nearby to location L are in nearproximity to certain other terminals in another network for certainproximity services. While each network (or network server) may knowwhich of its own terminals are in near proximity to one or more otherterminals served by the other network, it may not know the identities ofthese other terminals since they may not have been transferred by theother network (or network proximity server). While this informationlimits discovery of actual proximity (without additional informationtransfer such as that described later herein), it may also indicatelarge numbers of terminals in a network for which near proximity toterminals in another network has not occurred. The network may then bespared from attempting to discover actual proximity for these terminalswhich may save significantly on processing and signaling usage andthereby enable faster discovery of actual proximity for terminals forwhich near proximity was first established.

In certain example implementations, techniques may be implemented tosupport inter-network discovery of actual proximity. For example, incertain instances, information exchanged between networks (or networkproximity servers) to discover near proximity may be limited to justcoarse locations and associated proximity services and sent infrequently(e.g. every 10 minutes) as described previously, possibly making supportefficient. If near proximity is discovered between terminals in twonetworks for some proximity service P at or nearby to a location L, eachof the two networks may, for example, then send to the other network theidentities and locations of its own served terminals that subscribe toor make use of service P that may also be at or nearby to location L.Each network (or a proximity server in each network) may then, forexample, compare locations for terminals that use the same proximityservice P to determine which terminals may be in actual proximity. Incertain instances, information to discover actual proximity (such asterminal identities and terminal locations) may be exchanged more oftenbetween networks (or between network proximity servers) than informationthat is exchanged to discover near proximity, and may only need to referto terminals already discovered to be in near proximity. Although moredetailed information may then be exchanged more often to enablediscovery of actual proximity than to enable discovery of nearproximity, the restriction of the detailed information just to terminalsalready known to be in near proximity may limit the quantity ofinformation compared to what would be needed if the information were tobe sent for all terminals served by a network.

If a network N1 (or a network proximity server in network N1) may beable to reliably verify (e.g. authenticate) the proximity services usedby each of its own served terminals, the terminal identities transferredto another network N2 (or to a proximity server in network N2) may bethe real ones (e.g. may include a global identity of each terminal suchas a public user ID). These terminal identities may then be provided toother terminals served by network N2 (e.g. by a proximity server innetwork N2) along with the proximity services used by the terminals innetwork N1 after proximity is discovered between pairs of terminals innetworks N1 and N2. In this case, a terminal served by network N2 thatreceives the identity of another terminal served by network N1 that isin proximity to the terminal in network N2 can be sure that theproximity services supported or used by the terminal in network N1 arevalid and can then decide how to react to the reported proximity. Sincethe identity of the terminal in network N1 reported to the terminal innetwork N2 would be a real identity, the terminal in network N2 would bein a position to instigate communication with the terminal in network N1if this was required or useful to support the proximity service(s) forwhich proximity had been discovered.

If radio and not geographic proximity needs to be discovered, thepreceding method of discovering near proximity between terminals indifferent networks may continue to be used but discovery of actualproximity for terminals already discovered to be in near proximity maybe based on an ability to receive signals (e.g. with a strength greaterthan some threshold) transmitted by one terminal in one network toanother terminal in another network rather than on verifying aparticular maximum geographic separation. A network N1 (or a proximityserver in network N1) may then, for example, provide another network N2with characteristics of signals broadcast by terminals in network N1,e.g., to possibly allow easier acquisition by terminals in network N2that are in near proximity to terminals in network N1. In certaininstances, network N1 may assign frequency or frequency resources (e.g.,that network N1 owns) to terminals served by network N2 (e.g. toterminals in network N2 that are in near proximity to terminals innetwork N1) which the terminals in network N2 may use to broadcast theirpresence to terminals in network N1.

In certain example implementations, techniques may be implemented tosupport notification of proximity to Apps and/or users. Assuming thattwo terminals, e.g., T1 and T2, are discovered to be in actual proximityfor a particular proximity service, these terminals may be notified inthe case that proximity is discovered by a network or by a networkproximity server. For example, a network proximity server may convey toterminal T1 the identity of terminal T2 and the particular proximityservice for which proximity was discovered. Similar information may alsobe conveyed to terminal T2. In the case that proximity has beendiscovered by one or both terminals instead of (or in addition to) bythe network (e.g., using direct radio signaling between the terminals orby having signals from one terminal relayed to the other terminal viaone or more other intermediate terminals), the information on terminalidentities and proximity services may already be known to the terminals(or to some proximity engine or process running on each terminal) due tohaving been included in the signals sent from one terminal to the other.For both the network discovery and terminal discovery cases, one or moreapplications on the terminals supporting the particular proximityservice(s) may be informed of the discovered proximity (e.g. may beprovided with the identity of the other terminal discovered to be inproximity or provided with a means to communicate with this otherterminal) and/or the terminal user(s) may be informed accordingly.Subsequent behavior may be up to the Apps and/or users and may include,for example, different types of communication (e.g. speech, video, IM,data) or possibly no noticeable action (e.g. where users or Apps simplytake note of the proximity but defer any action to a later time,possibly when some other trigger event has occurred). In certaininstances, a proximity process or proximity engine on a terminal maycontinue to monitor proximity and inform Apps and/or users whenproximity to some other terminal for some proximity service has ceased,e.g., such an occurrence may trigger one or more other actions from theApps and/or users.

Broadcast and Relaying

In certain example implementations, techniques may be implemented tosupport proximity services without network support—e.g. when terminalsare outside of network coverage or when network support is not availableor cannot be relied upon. For example, if proximity services aresupported by terminals without the assistance or participation of eithera network or network based proximity server, terminals may employ directradio discovery. In certain instances, terminals whose broadcast signalsmay be directly received by some other terminal A may be considered tobe in actual proximity to terminal A (e.g., either without condition orif the received signals satisfy certain conditions). Here, for example,a condition may be satisfied if a signal level exceeds some thresholdand/or if the measured RTT between the terminals is below somethreshold. Terminals whose signals may not be received directly byterminal A (Group 1) or whose signals may be received but fall below therequired threshold(s) for actual proximity (Group 2) may be candidatesfor near proximity. For terminals in Group 2, a determination of actualrather than near proximity may be based, at least in part, on monitoredsignal levels and/or RTTs. For terminals in Group 1, a determination ofnear proximity to terminal A may, for example, be possible if eachterminal T in Group 1 relays to other terminals, by means of broadcast,information on all terminals whose signals have been directly detectedby the terminal T. For example, terminal A may then receive from thoseterminals B it is in direct contact with information on other terminalsC in direct contact with terminals B but not in direct contact withterminal A. Terminals B may, for example, also relay information onadditional terminals D not directly detected by terminals B butidentified via broadcast from other terminals (e.g. terminals C).Terminal A may thus receive information on all terminals whoseinformation can be sent to terminal A either directly (as in the case ofterminals B) or via relaying through other terminals (as in the case ofterminals C and D). Information broadcast by or relayed for otherterminals may, for example, be indicative of their identities, locationinformation (e.g., RTTs to other terminals and/or location coordinates),and/or their supported proximity services, just to name a few examples.In certain instances, terminal A may end up receiving information on allterminals and, by using the received location information, may be ableto determine which terminals may be in near proximity to terminal A. Incertain instances, terminal A may listen for direct radio signals fromterminals found to be in near proximity to terminal A in order todetermine which of these terminals may be in actual proximity toterminal A and/or may use received location information to determinewhen any of these terminals may be in actual proximity to terminal A.

In certain example implementations, relaying of information by terminalsmay have some limitations. For example, in certain instances, unless aterminal is surrounded by many terminals in different directions,information on some terminals in near proximity may not be relayed. Assuch, in certain implementations, a terminal may need to listen fordirect broadcasts from terminals not so far detected, in order to detectearly on when they are in actual proximity. In certain instances,relaying of information may consume significant bandwidth and/orpossibly be redundant (and possibly wasteful of resources), e.g.,whenever information on the same terminal is relayed to a terminal A bymore than one neighbor terminal or by the same neighbor terminalmultiple times. This may not always be important, however, whenterminals are out of network coverage because bandwidth may be plentiful(e.g. due to no interference with network used bandwidth). In certainimplementations, the consumption of bandwidth may be mitigated byrelaying information periodically at low frequency, e.g., every 5minutes. In certain instances, the discovery of near proximity for thecase of no network support may be used to support group communicationswherein being in near proximity may trigger relaying of communicationbetween terminal users.

FIG. 5 is an illustration showing an example arrangement 500 of mobiledevices (terminals A, B, C, D, E, and F) supporting the transmissionand/or relaying of information (e.g. for use in determining a state ofproximity or for supporting a certain proximity service) between two ormore of the mobile devices, in accordance with an exampleimplementation. Area 502 represents a limit of direct radio receptionfor terminal A, and area 504 represents a limit of direct radioreception for terminal B.

In this example, terminal A directly detects the presence of terminal B(from signals broadcast from terminal B) and can learn about terminal Cand terminal D from information relayed by terminal B. However, theremay be no terminal within radio coverage of terminal A that can relayinformation received directly from terminal E and terminal F even thoughthese may be in near proximity to terminal A. However, terminal E maybroadcast information to terminal F which may broadcast its owninformation and relay terminal E's information to terminal D which mayin turn relay this information to terminal B and thence to terminal A.Relaying may, for example, thus transfer information concerning eachterminal to all other terminals. Relaying information within a set S ofterminals in the above manner may be possible unless the set S contains2 or more subsets S1, S2 (, S3 . . . ) with each terminal in any subsetSi being out of radio range of every terminal in every other subset Sj.

In certain example implementations, a method of relaying informationamong a set of terminals without network support may be for everyterminal A to broadcast information for every other terminal B whoseinformation is received either directly from the terminal B or viarelaying from some other terminal C. This may result in each terminal inany set S of terminals broadcasting information for every other terminalin S provided no subset of S is out of radio range of any other subsetof S. This may, for example, produce unnecessary broadcast (andunnecessary extra use of bandwidth) as well as continuing to propagateout of date information (e.g. location information) for some terminals.To reduce unnecessary broadcast and/or avoid out of date information, incertain instances information on each source terminal may be tagged bythe source terminal in some manner, e.g., explicitly with a versionnumber V or timestamp TS and implicitly or explicitly with a duration D(where an implicit duration D could be a system parameter configured inall terminals). In certain implementations, a terminal T1 receivinginformation for a terminal T2 may only accept the information if theassociated version V or timestamp TS is higher than or later than theversion or timestamp, respectively, for any other information forterminal T2 received previously by terminal T1—otherwise the newlyreceived information may be ignored. If terminal T1 receives new (higherversion or later timestamped) information for terminal T2, it maybroadcast the new information for the duration D and may thereafterdiscard the information. A version V or timestamp TS used to taginformation for any source terminal may, for example, be incremented bythe source terminal even if there is no change in the information, e.g.,to ensure other terminals know the unchanged information is still up todate.

FIG. 6 is an illustration showing an example arrangement 600 of mobiledevices (represented by terminals A, B, C, D, E, and F) supporting thetransmission and/or relaying of information as described above betweentwo or more of the mobile devices, in accordance with an exampleimplementation. Here, terminal A is shown as being moved at some stageto a new location wherein terminal A is represented as A′ at the newlocation. In this example, terminal E may receive information related toterminal A both via relaying through a chain of terminal B, terminal C,terminal D which involves transmission of information on 4 consecutivehops and via relaying by terminal F which involves transmission ofinformation over only 2 consecutive hops. Hence, the information relayedby terminal F may arrive first (since there are fewer hops to delay theinformation) so terminal E may ignore the same information when receivedfrom terminal D. Suppose after some time period, terminal A moves (toA′) and is still within radio range of terminal B but out of radio rangeof terminal F. If terminal A broadcasts new information (e.g.information containing its new location) with a new version V+1,terminal E may now accept the new information from terminal D (due tothe higher version V+1) and may ignore any out of date informationbroadcast by terminal F which may still indicate version V. In addition,terminal F may accept the new information from terminal E, e.g., onceterminal E starts to broadcast such new information.

In certain example implementations, techniques may be implemented tosupport efficient relaying of information among terminals withoutnetwork support via means of acknowledgment(s). In certain exampleimplementations, a terminal T1 may stop broadcasting or relaying certaininformation (I) once it knows that all interested terminals withindirect radio range of T1 already have the information I. Anotherterminal T2 may, for example, effectively confirm receipt of I toterminal T1 via either explicit or implicit acknowledgment. By way ofexample, with an explicit acknowledgment, terminal T1 may observeterminal T2 broadcasting the same information I. For example, assuming Irelates to some terminal T3, I can be uniquely labeled using someidentifier for terminal T3 plus an information version V or timestamp TSassigned originally by terminal T3. For explicit acknowledgment of I,terminal T1 may observe terminal T2 broadcasting information forterminal T3 (e.g. labeled with the identifier for terminal T3) and withthe same version V or timestamp TS that terminal T1 already has).

In certain instances, with implicit acknowledgment, terminal T1 maybroadcast I together with a tag value TV unique to T1 (e.g., which maycomprise the ID of terminal T1 plus a sequence number assigned byterminal T1). Any terminal T2 that receives I together with TV directlyfrom terminal T1 may include TV in all broadcasts of its own andcontinues broadcasting TV so long as it receives I together with TV fromterminal T1. However, TV may not be relayed when I is received togetherwith TV from a terminal that is not terminal T1. Terminal T1 maycontinue to broadcast TV (or an updated version of TV) along with I,e.g., so long as I is broadcast. If terminal T1 observes terminal T2broadcasting TV (or an updated version of TV), it may determine thatterminal T2 has received I. In certain instances, TV may also be used byterminal T1 to tag other information items J broadcast or relayed byterminal T1. In some implementations, TV may be quite short (e.g. muchsmaller than the information I that TV is used to tag) and may thus be amore efficient means of acknowledging I than broadcast of I itself. Onceall terminals from which terminal T1 may receive broadcast directly haveexplicitly acknowledged I (e.g. via broadcast of I) or implicitlyacknowledged I (e.g. via broadcast of a tag value TV), terminal T1 maystop broadcasting or relaying I.

In certain instances, such explicit and implicit acknowledgmentmechanisms as those described above may allow more efficientbroadcasting and relaying. In an example implementation, a terminal T1may initially broadcast any updated information I1 for itself and mayinclude a higher version number V1 or later timestamp TS1 for I1.Terminal T1 may, for example, likewise relay any updated information I3received for another terminal T3 as indicated by a higher version V3 orlater timestamp TS3 (assigned by terminal T3) than previously receivedfor terminal T3 by terminal T1. Once all other terminals S from whichterminal T1 receives broadcasts directly have explicitly or implicitlyacknowledged I1 and/or explicitly or implicitly acknowledged I3,terminal T1 may cease broadcasting I1 and/or cease relaying I3 in eachcase respectively (e.g. in the case of I3, terminal T1 can then ignoreI3 when received from other terminals). In certain instances, terminalT1 may resume broadcast of I1 or resume relay of I3 if I1 is updated orterminal T1 receives a newer version of I3 (with a higher version V3+nor later timestamp TS3+x) in each case respectively. Terminal T1 maythen wait until the new information is acknowledged implicitly orexplicitly by all terminals in direct radio range before ceasingbroadcast or relaying. Terminal T1 may also resume broadcast of I1 orresume relay of I3 if T1 receives a direct broadcast from a new terminalnot in the previous set S that does not contain (or implicitlyacknowledge) I1 or I3, respectively, or contains an earlier version ofeither information. Terminal T1 may then wait until the new terminalexplicitly or implicitly acknowledges I1 or I3 (in each caserespectively) before ceasing broadcast or relaying.

The previous mechanism may not guarantee that a terminal T1 will alwaysreceive an acknowledgment from another terminal T2 for information Ibroadcast or relayed by T1. There may be cases where terminal T2 has Iand either (a) does not receive terminal T1's broadcasts directly or (b)observes terminal T1 broadcasting I and concludes that because terminalT1 (and all other terminals in range of terminal T2) has (have) I,terminal T2 does not need to send I. Case (b) above may be avoided ifterminal T1 employs implicit acknowledgment because terminal T2 maystill have to broadcast any tag value TV sent by T1 in association withI which will then implicitly acknowledge I to terminal T1. For case (a)above, terminal T1 may observe terminal T2 not broadcasting I andconclude terminal T2 does not have I, leading terminal T1 to keepsending I. Case (a) may be fairly rare because it depends onunsuccessful terminal T1 to terminal T2 transmission and successfulterminal T2 to terminal T1 transmission, but may be possible due todifferent transmission powers and receiver sensitivities in terminal T1and terminal T2. To mitigate case (a), in certain instances a terminalmay periodically resend any information I even when all terminals indirect radio contact appear to have acknowledged I. In the exampleabove, this would lead terminal T2 to periodically resend I andtherefore confirm receipt to terminal T1 enabling T1 to cease sending I.In addition whenever information I changes, terminals may send the newerversion of I which will terminate transmission of the older version of Iin terminals such as terminal T1 above.

Reference is now made to FIG. 20, which is a flow diagram illustrating aprocess 2000, which in accordance with certain example implementations,may be implemented to support all or part of an example generalbroadcast and relaying method among terminals without network support.In support of such a method at example block 2002, each terminal maystart by periodically broadcasting information for itself comprisingand/or other indicating, for example, its identity, current location andsupported proximity services and an information version or timestamp.Each terminal may also listen at example block 2004 for broadcasts fromother terminals (e.g. when not engaged in performing block 2002) and maystore any information received from other terminals. If a terminalreceives information from some other terminal, the received informationmay at example block 2006 be combined with other information previouslyreceived such that any received information with version V or timestampT that is related to some terminal T1 replaces any previous informationfor terminal T1 that has a version less than V or a timestamp prior toT. A terminal may continue to broadcast information for itself atexample block 2008 (e.g., as at block 2002) but once the terminal hasreceived information related to one or more other terminals at blocks2004 and 2006, the terminal may also relay such information along withits own information. At example block 2010, a terminal T1 may determinethat another terminal T2 has acknowledged information that terminal T1sent previously related to some terminal T3, if information is receivedfrom terminal T2 that implicitly or explicitly acknowledges thisinformation (e.g., as described previously). It should be noted thatterminal T3 at block 2010 may be a different terminal to T1 or may beterminal T1. At example block 2012, if all terminals from which terminalT1 receives broadcast explicitly or implicitly acknowledge theinformation stored in terminal T1 for any terminal T3, terminal T1 maycease relaying information for terminal T3. At example block 2014, aterminal T1 may later resume relaying information for a terminal T3,e.g., after receiving new information for terminal T3 (e.g. with ahigher version or later timestamp) or after receiving a direct broadcastfrom some terminal T4 that did not yet acknowledge the informationstored in terminal T1 for terminal T3.

In certain example implementations, techniques may be implemented tosupport relaying of information between terminals without networksupport using information tags. The techniques support an explicitrequest for transmission of missing information and are referred to hereas “tagged transmission”. The previous explicit and implicitacknowledgment mechanisms may, in certain situations, produceunnecessary broadcasting (e.g., until a sender receives sufficientacknowledgments to cause the sender to stop sending). To reduceunnecessary transmission further, tagged transmission may be used inwhich information items may be associated with a unique tag. Forexample, information related to a particular terminal T1 may have a tagcomprising the terminal T1's identity (ID), an information type orinformation identifier and a version number or timestamp. In oneimplementation, a tag t related to information i for a particularterminal t1 may be generated by terminal t1, broadcast by terminal t1along with i and subsequently relayed along with i by other terminals. Aterminal T1 that receives or internally generates information I with tagT may then relay or broadcast, respectively, I and T together a fewtimes and subsequently just relay or broadcast T (without I) which maybe much smaller than I. A terminal T2 that detects terminal T1 relayingor broadcasting T but not I may then broadcast a request for 1 if itdoes not yet have I (or only has an earlier version of I associated witha tag with a lower version number or earlier timestamp) by sending thetag T together with a request indication. Terminal T2 may, for example,determine, at least in part, from the content of the tag (e.g. from anyterminal ID and information type identifier in the tag) whether or notterminal T2 wishes to receive I and thus whether or not to request I bybroadcasting a request indication together with the tag T. Shouldterminal T2 decide to request I, terminal T2 may, for example,optionally include terminal T1's ID as well as the tag T in the requestto indicate that terminal T1 but not other terminals should transmit I.The inclusion of terminal T1's ID in the request may avoid additionaltransmission from other terminals. If terminal T1 detects the requestfor 1 from terminal T2, terminal T1 may send I and T together once orseveral times so that terminal T2 may obtain I. If terminal T2 does notreceive I, it may repeat the request and terminal T1 may repeat sendingI. Once terminal T2 has information I, it may signify this to terminalT1, e.g., by broadcasting just the tag T without I and not inassociation with a request. As an alternative to requesting transmissiononly from terminal T1, terminal T2 may send a request for 1 but notinclude the ID of terminal T1, in which case any other terminal that hasthe information I and the associated tag T, may broadcast I and T onceor several times to enable receipt by terminal T2.

For simplicity and efficiency, in certain example implementations oftagged transmission, a request for information I associated with a tag Tmay optionally be signaled by a null request. In this case, a terminalT1 may assume another terminal T2 requests information I that isassociated with a tag T if terminal T1 does not see terminal T2 sendingeither I and T together or just T without I. With this implementation,each terminal t1 may periodically send either the latest information iand associated tag t for every other terminal t2 or just the tag twithout the information i. The lack of receipt of either i and t (or alater version of I and t) or just t (or a later version of t) from someother terminal t3 may then be taken as evidence that the terminal t3does not have information for the terminal t2 and thus needs to be sentthe information i and associated tag t. The use of a null request may beefficient when information needs to be sent to all terminals (e.g.terminals will not be able to selectively request or not requestdifferent information items).

When tagged transmission is used as described above (and with or withoutthe use of a null request), a terminal T1 may resume sending anyinformation I associated with a tag T whenever it receives (orinternally generates) a later version of I associated with a new tagwith a higher version or later timestamp than that for the previous tagT. For an asymmetric case where a terminal T1 may receive signals fromanother terminal T2 but where terminal T2 is unable to receive signalsfrom terminal T1, terminal T1 will not be able to send I to terminal T2even if sees a request for 1 from terminal T2. Since terminal T2 wouldhave learnt of I from some terminal (which would generally not be T1since it is assumed that T2 cannot receive from T1), there is a chancethat another terminal (that is not T1) may be able to send I to terminalT2. If not, terminal T1 may observe T2 requesting I and consequently maysend I but without T2 being able to receive I. In this case, theunnecessary transmission from terminal T1 may, in certain instances,still be limited by a limit on the number of transmissions of I from anyterminal that may be imposed for the tagged transmission technique. Inanother asymmetric case where a terminal T2 may receive signals fromterminal T1 but terminal T1 is unable to receive signals from terminalT2, the terminal T2 may request I but terminal T1 will not see therequest. Terminal T2 may, for example, repeat the request for 1 manytimes without receiving I, but if the size of T is small, this may notuse much bandwidth. In general, tagged transmission schemes may beefficient when the information I size is large and the tag T size issmall which may arise when information is exchanged among terminalswithout network support via broadcast and relaying to support individualproximity services after proximity or near proximity has beendiscovered.

Information for a terminal T that is broadcast or relayed among otherterminals may be used to support discovery of the terminal T by one ormore of the other terminals for different proximity services and may beused to assist proximity services being used by the terminal T. Forexample, a set of information A related to a terminal T that isbroadcast by terminal T and/or relayed by other terminals to supportdiscovery of proximity for T may be indicative of an identity of theterminal T, a list of proximity services supported by T (e.g. with eachproximity service identified by means of a unique expression),identities of other terminals T* known by T to be in direct radio rangeof T, and/or location and signal information for T and terminals in T*,just to name a few examples. A different set of information B related toterminal T that is used to assist proximity services in use by T may beindicative of: (i) message(s) for any proximity service P in use by Tthat is (are) intended to be transferred to other terminals in proximityto T; (ii) identities of terminals previously discovered to be inproximity to T (which may constitute a recipient list for theinformation); (iii) information to setup or release sessions orconnections between T and other terminals in proximity to T; and/or (iv)data traffic between T and other terminals in proximity to T (e.g.speech/video clips, IM), just to name a few examples. In certaininstances, information sets A and B above may be distinguished andsupported differently, e.g., using different protocols and differentbroadcast and relay mechanisms for information set A versus informationset B. In certain instances, information set B for terminal T that isused to assist proximity services in use by T may be transferred toother terminals via a more efficient means of broadcast and relayingthan information set A that is used to support discovery of proximity byor for T. This may be due to a likelihood of information set B beingmuch greater in size than information set A.

In certain example implementations, techniques may be implemented tosupport routing of certain communication between terminals. The previousexample mechanisms (e.g. using explicit acknowledgment, implicitacknowledgment and tagged transmission) may enable information to bebroadcast and relayed throughout a group of terminals without networksupport but may not be suitable for directed communication, e.g., wherea terminal may need to send signaling, data or voice to just one otherterminal or to a particular group of terminals within a larger set ofterminals. In some instances, in order to support directedcommunication, each terminal T may support a hop by hop method ofrouting by maintaining a routing table showing other terminals in directradio range of T via which communication can be transferred to any otherdestination terminal. Such a routing table may, for example, be compiledvia information received by each terminal as part of proximity discoverysupport (e.g. as enabled by broadcast and relaying of information itemsin information set A described previously herein). In certainimplementations, a routing table at a terminal T may be next hopbased—showing, for each destination terminal D, other terminals S indirect radio range to terminal T via which information can be relayedfrom T to the destination terminal D. In certain instances, such a tablemay identify a subset of terminals S* in S that are able to relayinformation to terminal D via a minimum number of additional relayterminals. If terminal T needs to send or relay a message to terminal D,it may forward the message to some terminal t in S*. If S* contains morethan one terminal, t may, for example, be chosen by T from within S* (a)at random, (b) based on known (e.g. reported) relay or throughputcapabilities of each terminal in S*, (c) based on a reported congestionstatus of each terminal in S* or (d) via some combination of (a), (b)and (c). The terminal t to which terminal T forwards the message wouldthen (if it is not the destination D) forward the message to anotherterminal using the same routing method as used by terminal T.Eventually, the message may reach the destination D via a minimum numberof intermediate relay terminals (or hops). Terminal T may maintainsignaling links or data links to the terminals in S, e.g., so messagesmay be efficiently forwarded. In certain implementations, a routingtable at terminal T may instead enable source routing by providing acomplete sequence of intermediate relay terminals via whichcommunication may be routed to any destination terminal D from terminalT. Such a source routing table may be compiled by any terminal T basedon information received from terminals related to discovery of proximity(e.g. based on information of the type described previously forinformation set A). In certain instances, terminal T may include in anymessage to be sent to a destination terminal D using source routing asequence of the intermediate relay terminals via which the message maybe relayed in order to allow each intermediate relay terminal todetermine the next terminal to which the message should be sent.

In certain example implementations, techniques may be implemented tosupport broadcast and relaying of information among terminals to supportvarious group services. In certain instances, a group of terminals inproximity to one another may use a group proximity service, e.g., (i)enabling one user to communicate with all the other users in the groupor communicate selectively with some of the other users or (ii) enablingone terminal to exchange information automatically with some or all ofthe other terminals in the group (e.g. location information and sensorinformation for the environment). Such group proximity service(s) may beused for public safety and by various closed user groups, e.g.,associated with a particular company, a club, a gaming service or someprivate interest group, just to name a few examples. To support suchgroup service(s), it may be beneficial for each terminal to be informedof the identities of other terminals engaging in the same service, andwhich may be in proximity (or possibly in near proximity). To establishproximity without any network support (e.g., when terminals are out ofnetwork coverage), the previous methods of broadcast and relaying and/orthe like may be used.

Use of a Proximity Server

In certain example implementations, techniques may be implemented forserver support of proximity discovery. In such a case, a network thatsupports discovery of proximity for the terminals that it serves maycontain a server, referred to here as a “proximity server” or “networkproximity server”, that enables discovery of terminals that use or havean interest in the same proximity service(s) and are in proximity to oneanother. Information concerning terminals discovered to be in proximityto one another may then be transferred by the proximity server to theconcerned terminals to enable the terminals (or certain applications onthe terminals or the terminal users) to engage in proximity services ofmutual interest to one another. In certain example implementations fornetworks that support LTE, a network proximity server may obtainproximity data for all UEs in a served area directly from the UEs and/orfrom MMEs and eNodeBs in the network that serve these terminals. Incertain instances, a proximity server may comprise a new entity or a newlogical function in an existing entity or subsystem (e.g., eNodeB, MME,PDG, IMS, SLP, E-SMLC) and may reside in a serving network for a UE.

In certain example implementations, a network proximity server may scandata it receives that is related to UEs in its serving area forpotential proximity matches. For example, a network proximity servermay: (i) find all UEs using or having an interest in the same proximityservice; (ii) authenticate UE association with each proximity servicethat a UE claims is used or of interest; (iii) verify geographic,cellular or probable radio proximity conditions for UEs that make use of(or have an interest in) the same proximity service; and/or (iv) where aset S of UEs using or interested in the same proximity service arediscovered to be in proximity, send data on each UE in S to some or allof the other UEs in S according to which UEs in S are allowed to receivethis data.

In certain example implementations, a network proximity server mayinstead or in addition broadcast all proximity data that it receives(e.g. from UEs, MMEs, eNodeBs) to all UEs served by the network with UEsthen responsible for proximity discovery. In certain instances, databroadcast in each network cell may comprise data applicable only to UEsin or nearby to the cell to reduce the amount of broadcast data.

In certain example implementations, a UE (or the serving MME/eNB for aUE) may update data in a proximity server (related to discovery ofproximity) periodically or whenever there may be some change in thedata. By way of example, certain updated data for a particular UE mayindicate a change of UE serving cell, a change of UE location, a changeof a set of other UEs detected by the UE via LTE-D, and/or a change ofuser or App requirements in the UE related to a certain proximityservice.

In certain example implementations, a network proximity server mayremove data it has for a UE following a timeout, e.g., in response tonot receiving further data updates from the UE. In certain instance, anetwork proximity server may receive proximity data (e.g. for networkdefined proximity services) via certain operations and maintenancefunctions, and/or from other network servers, etc. In someimplementations, network proximity server support may not be needed forproximity services that only make use of radio proximity and can besupported by terminals without network assistance.

In certain example implementations, techniques may be implemented forLTE-D support and discovery of proximity by a network proximity server.For example, in certain implementations, proximity discovery byterminals using direct radio signaling (e.g. LTE-D) may be enabled torun autonomously for some user cases—e.g. public safety. In certaininstances, network control of direct radio (e.g. LTE-D) discovery may beoptional. For example, a network may inform UEs whether or not directradio discovery may be permitted and provide physical and transportrelated parameters to assist terminals to discover proximity (e.g. mayprovide frequencies and signaling related parameters that terminalsshould all use for direct radio discovery). In some instances, ifnetwork control is absent (e.g., not implemented), proximity servicesmay simply be unavailable or may be supported using default informationconfigured in each terminal (e.g. permitted spectrum in the case ofproximity services for public safety).

In certain example implementations, discovery of proximity by a networkproximity server may be optional and may instead be supported by UEs ifrequested by the serving network. In certain instances, some networkcontrol parameters for proximity discovery may be broadcast to terminalsand/or provided to terminals on network attachment or (for IMS control)on IMS registration. Network control parameters may, for example,specify how interaction between terminals and the network proximityserver may operate, e.g., whether UEs need to send data to a proximityserver concerning UEs discovered via direct radio contact. In certaininstances, discovery by network proximity servers of proximity betweenterminals served by different networks may need to take account of UEsubscription data or user preferences—e.g. in order to protect UE oruser identities when sending proximity related information to anothernetwork and/or restrict the degree to which a terminal in one networkcan be discovered to be in proximity to a terminal in another network.In certain implementations, applications may attempt to set proximityservice parameters to maximize use of direct radio discovery (due tonormal higher efficiency than network discovery of proximity).

Attention is drawn next to FIG. 14, which is a schematic block diagramillustrating an example arrangement 1400 in which discovery of proximitybetween nearby devices is discovered by or with the assistance of anetwork proximity server in an LTE network that makes of control planebased signaling to communicate with other entities. As illustrated,example arrangement 1400 may comprise an eNB 1404 coupled to a UE 1402and also an MME 1406. MME 1406 may be coupled to a proximity server 1408and possibly to an E-SMLC 1410. In certain implementations, asillustrated by the dashed-line box, proximity server 1408 and E-SMLC1410, though logically separate, may be physically combined, e.g., tobenefit from proximity & location synergies, etc., or may be physicallyseparate and enabled to communicate via a communications link. Controlplane based signaling may be supported between UE 1402 and proximityserver 1408, for example, using NAS capabilities and NAS signaling thatmay be partly defined already for 3GPP networks in such 3GPP TSs as TS24.301. Proximity server 1408 may obtain proximity related informationfor UE 1402 (e.g. UE identity, UE location, UE serving cell, serving eNBor TA, nearby UEs detected by direct radio means, proximity servicessupported by or of interest to the UE) directly from UE 1402 (e.g. usingthe aforementioned NAS signaling) and/or from eNB 1404 and/or MME 1406.Location related information for UE 1402 may in addition or instead beobtained by proximity server 1408 from E-SMLC 1410. To locate a targetUE (e.g. UE 1402), proximity server 1408 may send a location request to(serving) MME 1406 for UE 1402. In certain instances, MME 1406 maytransfer such a request to E-SMLC 1410 which may then locate UE 1402using 3GPP control plane procedures (e.g. as defined in 3GPP TS 36.305)and return the location result to MME 1406 and thence to proximityserver 1408. Proximity server 1408 may use the information obtained forUE 1402 and other UEs to determine which UEs may be in proximity or nearproximity and/or to predict the probable future occurrence of proximityas described elsewhere here. Proximity server 1408 may then inform UEs(e.g. UE 1402) discovered to be in proximity to other UEs using controlplane signaling.

Attention is next to FIG. 15, which is a schematic block diagramillustrating an example arrangement 1500 in which discovery of proximitybetween nearby devices is discovered by or with the assistance of anetwork proximity server in an LTE network that makes of user planebased signaling to communicate with other entities. In contrast tocontrol plane support as illustrated in FIG. 14, user plane support mayreduce impacts to network eNBs and MMEs to support discovery ofproximity. Example arrangement 1500 may comprise an eNB 1504 coupled toUE 1502 and also an MME 1506. MME 1506 may be coupled to a proximityserver 1512. As shown, eNB 1504 may be coupled to an SGW 1508, which maybe further coupled to a PDG 1510. PDG 1510 may be coupled to proximityserver 1512 and to a SUPL SLP 1514, and proximity server 1512 may becoupled to SLP 1514. In certain implementations, as illustrated by thedashed-line box, proximity server 1512 and SLP 1514, though logicallyseparate, may be physically combined, e.g., to benefit from proximity &location synergies, etc.

In this example, two potential signaling paths are indicated, the firstcomprising MME-Proximity Server Signaling (e.g., which may addefficiency), and the second comprising UE-Proximity Server Signaling. Asfor a control plane based proximity server (e.g. server 1408 in FIG.14), proximity server 1512 may obtain information to support discoveryof proximity between UEs directly from the UEs (e.g. UE 1502) using userplane signaling in which information may be sent in the form of data(e.g. using TCP/IP) from a network perspective. The information may besimilar to or the same as in FIG. 14—e.g. may include UE identity, UElocation, UE serving cell, serving eNB or TA, other nearby UEs detectedand proximity services supported by or of interest to the UE. Proximityserver 1512 may also obtain some or all of this information from MME1506 if proximity server 1512 is linked to MMEs. In certainimplementations, a proximity server address (e.g. the IP address or theFQDN for proximity server 1512) may be discovered by UE 1502 (e.g. usingthe IETF DHCP protocol) or may be provided to UE 1502, e.g., on networkattachment by MME 1506 or on connection to PDG 1510 or may be broadcastto all UEs by eNBs such as eNB 1504. UE 1502 may then use the discoveredaddress for proximity server 1512 to transfer data to proximity server1512 and/or request data from proximity server 1512. In some instances,proximity server 1512 may use a (SUPL) SLP 1514 to assist with UElocation. Thus, for example, proximity server 1512 may send a locationrequest for some target UE directly to an associated SLP 1514 afterwhich SLP 1514 may invoke SUPL to locate the UE and return the locationto proximity server 1512.

Attention is drawn next to FIG. 16, which is a schematic block diagramillustrating an example arrangement 1600 in which discovery of proximitybetween nearby devices is discovered by or with the assistance of anetwork proximity server that makes use of IMS based signaling tocommunicate with other entities. Example arrangement 1600 may supportUE-proximity server signaling in an LTE network and may comprise an eNB1604 coupled to UE 1602 and also an MME 1606. As shown, eNB 1604 may becoupled to an SGW 1608, which may be further coupled to a PDG 1610. PDG1610 may be coupled to an SLP 1612 and to an IMS 1614. In this example,IMS 1614 may comprise a P-CSCF 1616, coupled to PDG 1610 and to anS-CSCF 1618. S-CSCF 1618 may be coupled to a proximity server 1622.Proximity server 1622 may be coupled to an LRF 1620. Proximity server1622 may function as an IMS Application Server (AS) in someimplementations. In certain implementations, as illustrated by thedashed-line box, proximity server 1622 and LRF 1620, though logicallyseparate, may be physically combined, e.g., to benefit from proximity &location synergies, etc. As for a control plane or a user plane basedproximity server (e.g. server 1408 in FIG. 14 or server 1512 in FIG.15), proximity server 1622 may obtain information to support discoveryof proximity between UEs directly from the UEs (e.g. UE 1602) using IMSbased signaling in which information may be sent in the form of data andcontained in SIP messages. The information may be similar to or the sameas in FIGS. 14 and 15—e.g. may include UE identity, UE location, UEserving cell, serving eNB or TA, other nearby UEs detected and proximityservices supported by or of interest to the UE.

In certain implementations, proximity server 1622 may reside in the homenetwork of UE 1602 rather than in the serving network for UE 1602(except when the serving network for UE 1602 is the home network).However, in certain instances this variation may be unable to detectproximity for roaming UEs without some further interaction between thehome network of a roaming UE and the serving network of the UE (e.g.involving interaction between the proximity servers in differentnetworks). In certain implementations, it may be beneficial to make useof certain (new) SIP signaling parameters. One advantage may beproximity support of certain IMS services, e.g., use of LTE-D fornetwork offload, which may trigger IMS communication between two UEs,e.g., after proximity is detected.

Protocol Aspects

In certain example implementations, techniques may be implemented tosupport various protocol aspects that may be implemented in certainexample proximity services. In certain example implementations, anetwork proximity server may be based on control plane (CP) or userplane (UP) signaling support—e.g. as described previously for FIG. 14and FIG. 15, respectively. In certain instances, a network proximityserver may be located in a serving network (e.g. not necessarily a homenetwork) with respect to all UEs served by this network that make use ofor have an interest in proximity services. In an example network mode ofoperation, such UEs may have network connectivity and the network mayassist with discovery of proximity and with enabling communication viadirect radio means (e.g. LTE-D) for certain UEs found to be inproximity. In an example LTE-D mode of operation applicable to an LTEnetwork, such UEs may discover proximity using LTE direct (LTE-D)signaling between one another. In certain instances, an LTE-D mode ofoperation may be used without network support (e.g., if there is nonetwork coverage) or with network support (e.g., when proximitydiscovery may be supported via (i) LTE-D signaling between UEs and (ii)a network proximity server that may receive information from UEsobtained via LTE-D signaling and then proceed to discover cases ofproximity using this information). In certain example implementations,protocol layering for ProSe support may extend existing CP and UPprotocol layering for LTE, e.g., as defined in 3GPP TS 23.401.

Attention is drawn next to FIG. 7 and FIG. 8, which illustrate someexample control plane protocols that may be implemented to transmit,receive and/or relay information for use in determining a state ofproximity between two or more mobile devices in an LTE network, inaccordance with an example implementation. FIG. 7 shows example CPProtocols 700 that may support a network mode using a network CPProximity Server—e.g. as described earlier in association with FIG. 14.Included in CP Protocols 700 are corresponding protocol stacks 702 (fora UE), 704 (for an eNB), 706 (for an MME), and 708 (for a network CPProximity Server). CP Protocols 700 may be applicable if a network usesa CP proximity server and provides protocol support for signalingbetween example network resources and a UE. As shown, an example stack702 may comprise various layers such as an L1, MAC, RLC, PDCP, RRC, NAS,and a PDP (Proximity Discovery Protocol). As shown, an example stack 704may comprise various layers such as an L1, L2, MAC, IP, RLC, PDCP, SCTP,RRC, and S1-AP. As shown, an example stack 706 may comprise variouslayers such as an L1, L2, IP, SCTP, S1-AP, PS-AP (Proximity ServicesApplication Protocol), and NAS. As shown, an example stack 708 maycomprise various layers such as an L1, L2, IP, SCTP, PS-AP, and PDP. Allprotocol layers except for the PS-AP and PDP layers may function asdescribed in 3GPP and other (e.g. IETF) standards. For example the NAS,RRC, S1-AP, MAC, RLC and PDCP protocol layers may operate as describedin 3GPP TSs 24.301, 36.331, 36.413, 36.321, 36.322 and 36.323respectively whereas the SCTP protocol layer may operate as described inIETF RFC 4960. The PS-AP and PDP layers may be new layers definedspecifically for support of proximity services using a network basedproximity server. As shown in FIG. 7, protocol layers may be paired tosupport communication between a pair of entities which may either bedirectly connected (e.g. to support communication by lower protocollayers) or separated by one or more intermediate entities functioning asrelays.

FIG. 8 shows example CP Protocols 800 similar to those in FIG. 7 thatmay support an LTE-D Mode in which a pair of UEs communicate directlywith one another. Included in CP Protocols 800 are correspondingprotocol stacks 802 (for a first UE) and 804 (for a second UE). CPProtocols 800 may be applicable for signaling between the first andsecond UE and may be applicable both when proximity is discovered by UEswith little or no network support and when proximity is discovered usinga network proximity support (e.g., based on protocols described for FIG.7 or described later for FIG. 9). As shown, example stacks 802 and 804may comprise various (corresponding) layers such as an L1, MAC, RLC,PDCP, RRC, NAS, and PDP*.

PDP may represent a protocol layer that may be used to discoverproximity services, e.g., in accordance with various techniques providedherein. In certain implementations, different variants of PDP may beused in network mode (as shown in FIG. 7) versus LTE-D mode (e.g. asshown in FIG. 8) or different protocols could be used. Accordingly, FIG.8 is illustrated using a PDP* layer that may be similar to but notnecessarily identical to the PDP layer shown in FIG. 7. For example, PDPand PDP* could share common procedures, messages and parameters but someprocedure, messages and/or parameters may be different.

Attention is now drawn to FIG. 9 and FIG. 10, which illustrate someexample user plane protocols that may be implemented to transmit,receive and/or relay information in an LTE network for use in (i)determining a state of proximity between two or more mobile devices inthe case of FIG. 9 and (ii) transferring data, voice or other mediabetween a pair of UEs in the case of FIG. 10, in accordance with anexample implementation. FIG. 9 shows example UP Protocols 900 that maysupport a network mode using a network UP Proximity Server—e.g. asdescribed earlier in association with FIG. 15. Included in UP Protocols900 are corresponding protocol stacks 902 (for a UE), 904 (for an eNB),906 (for an SWG), 908 (for a PDG), and 910 (for a network UP ProximityServer). UP Protocols 900 may be applicable if a network uses a UPproximity server and provides protocol support for signaling between thenetwork and UE. As shown, an example stack 902 may comprise variousprotocol layers such as an L1, MAC, RLC, PDCP, IP, TCP/TLS, and PDP. Asshown, an example stack 904 may comprise various layers such as an L1,L2, MAC, RLC, UDP/IP, PDCP, and GTP-U. As shown, an example stack 906may comprise various layers such as an L1, L2, UDP/IP, and GTP-U. Asshown, an example stack 908 may comprise various layers such as an L1,L2, L3, UDP/IP, GTP-U, and IP. As shown, an example stack 910 maycomprise various layers such as an L1, L2, L3, IP, TCP/TLS, and PDP. Alllayers except the PDP layer may function the same as described in 3GPP,IETF and other standards, Thus, for example, the MAC, RLC, PDCP andGTP-U protocol layers may operate as described in 3GPP TSs 36.321,36.322, 36.323 and 29.060, respectively whereas the UDP, TCP and TLSprotocol layers may operate as described in IETF RFCs 768, 793 and 4346,respectively. The PDP layer may be a new layer defined specifically forsupport of proximity services using a network based proximity server andmay be similar to or the same as the PDP layer shown in FIG. 7. As shownin FIG. 9, protocol layers may be paired to support communicationbetween a pair of entities which may either be directly connected (e.g.to support communication by lower protocol layers) or separated by oneor more intermediate entities functioning as relays.

FIG. 10 shows example UP Protocols 1000 that may support transfer ofdata related to support of proximity services between applicationsresident in two UEs using LTE-D mode. Included in UP Protocols 1000 arecorresponding protocol stacks 1002 (for a first UE) and 1004 (for asecond UE). UP Protocols 1000 may be used to support peer to peer (P2P)signaling between applications that support particular proximityservices (e.g., for public safety) and can be applicable when networksupport is available for discovering proximity (e.g. as described inassociation with FIGS. 14, 15 and 7) or when proximity is discovered byUEs with little or no network support (e.g. as supported by the protocollayering in FIG. 8)). As shown, example stacks 1002 and 1004 maycomprise various (corresponding) layers such as an L1, MAC, RLC, PDCP,IP, TCP/TLS, and an applicable (App) layer that is specific to theproximity service or services supported by the communicatingapplications. In certain instances, TLS and TCP over IP may be used tofirst establish a secure and reliable connection between the pair ofendpoint entities in each figure—e.g. between the UE and UP proximityserver in FIG. 9 and between the pair of UEs in FIG. 10. Secure andreliable communication may then occur at the PDP level in FIG. 9 and atthe application (App) level in FIG. 10.

In certain example implementations, techniques may be implemented tosupport ProSe signaling in an LTE network using the RRC protocollayer—e.g. as in association with the protocol layering described forFIGS. 7 and 8. In some implementations, certain RRC roles may be commonto both a network mode of operation as shown in FIG. 7 and an LTE-D modeof operation as shown in FIG. 8. For this common mode of operation, RRCmay be used to broadcast (or, for LTE-D mode, relay) information usedfor proximity discovery using new LTE SIBs dedicated to supportingLTE-D. For example, a terminal (UE) may broadcast using a new SIB theidentity of the terminal (e.g., a temporary network assigned identity ora global permanent identity of the terminal) and expressions identifyingproximity services of interest to the terminal. Information receivedfrom another UE at the RRC level (e.g. an identity of the other UE andexpressions of interest to the other UE) may be passed up to the NASprotocol layer by the RRC layer inside the receiving UE and may then bepassed to the PDP layer inside the UE.

Other RRC roles may be specific to supporting proximity services betweena pair of terminals in LTE-D mode—e.g. according to the protocollayering described for FIG. 8. For support of LTE-D mode, someinformation transferred by RRC may be broadcast (and/or relayed) toother UEs using signals that may be highly detectable, e.g., similar toa Positioning Reference Signal used to support LTE positioning (e.g. asdescribed in 3GPP TS 36.211) and orthogonal to other signals infrequency, coding or time. RRC may also be used to establish and releaseLTE-D signaling connections between pairs of UEs. RRC may be furtherused to establish multipoint LTE-D links between groups of three or moreUEs, e.g., where transmission from any one UE may be received by all theother UEs in any group. RRC may also be used to establish, modify andrelease point to point (or multipoint) traffic bearers between two (orthree or more) UEs associated with subsequent UP communication of dataor media to support particular proximity services (e.g. according to theprotocol layering shown in FIG. 10). RRC may be used to help establishtime synchronization between two or more UEs (e.g., in the absence of acommon network or other (e.g. GPS) time) which may help avoidoverlapping LTE-D transmission by the UEs and thereby improve thereliability of LTE-D communication. In certain instances when the timingin UEs is synchronized using RRC (or using some common time referencesuch as GPS or network timing), UEs may broadcast and relay informationto one another at different non-overlapping transmission times. Incertain instances, these transmission times may be made available toother UEs, e.g., so UEs may know when to listen for other UEs. Beforetime synchronization is established between UEs, the UEs may send onlysmall amounts of data to one another using LTE-D, e.g., possibly atrandom times. Once the UEs are time synchronized, the amount of data andsignaling transfer using LTE-D between the UEs may significantlyincrease. If a network is available, commonly available network timeeither from one eNB or from multiple synchronized UEs may be used toachieve time synchronization among UEs, in certain implementations. Incertain example implementations, RRC may be used in LTE-D mode tomeasure RTTs between pairs of UEs and thereby help establish whether theUEs are in proximity.

In certain example implementations, techniques may be implemented tosupport ProSe signaling in an LTE network using the NAS protocollayer—e.g. as in association with the protocol layering described forFIGS. 7 and 8. For example, a role of the NAS protocol layer (e.g. whena network proximity server is used as described for FIG. 14 and/or whenprotocol layering is as shown in FIG. 7) may include relayinginformation between a CP proximity server and a UE, e.g., via an MME. Incertain instances, NAS may be used to help acquire certain proximityrelated information (e.g., timing advance, serving eNB, proximityservices of interest) by an MME from a UE which the MME may then conveyto a proximity server. In certain implementations, a role of NAS inLTE-D Mode (e.g., in association with the protocol layering shown inFIG. 8) may include establishing (and later releasing) signalingconnections and sessions between pairs or groups of UEs over whichproximity related information may be transferred, e.g., at the PDPlevel. In certain instances, this connection and session setup andrelease may be based on (e.g. may be similar to) that supported in NASbetween a UE and an MME as defined in 3GPP TS 24.301. NAS may, in someimplementations, be used between a pair of UEs (e.g. according to theprotocol layering shown in FIG. 8) to setup and release data bearersbetween pairs of UEs already in proximity to one another to supportUE-UE communication for particular proximity services supported bycertain Apps, e.g., with the UE-UE communication then occurring usingthe UP Protocols 1000 (FIG. 10). In certain implementations, NAS may beused (e.g. with the protocol layering shown in FIG. 8) to transportsignaling messages between UEs on behalf of ProSe Apps as an alternativeto transferring these messages using data bearers with UP protocollayering (e.g. as in FIG. 10).

In certain example implementations, techniques may be implemented tosupport ProSe signaling in an LTE network using a PS-AP (ProximityServices Application Protocol) Layer for ProSe Signaling, e.g., for anetwork mode with a CP Proximity Server (e.g. as in FIG. 14 and FIG. 7).In certain instances, a PS-AP protocol may enable exchange ofinformation between a CP proximity server and an MME. For example, aPS-AP protocol may enable an MME to transfer to a proximity server theIDs of UEs attached to the MME, the current serving eNB or serving TAfor each UE and the proximity services (and associated parameters) eachUE subscribes to. Such transfer may occur on request by the proximityserver or when a UE attaches to the serving network or changes itsserving MME or under other conditions. In certain implementations, aPS-AP protocol may enable a request from a proximity server to an MMEfor the locations of one or more UEs attached to the MME. For any suchUE location request sent to the MME, the MME may relay the locationrequest to an attached E-SMLC which may locate the UE using the 3GPP CPlocation solution defined in 3GPP TS 35.305. In some instances, such adirect location request between a CP proximity server and an MME may bemore efficient than sending a location request to an MME via a GMLC. Incertain example implementations, a PS-AP protocol may also be used totransport information between a proximity server and one or more UEs viaan MME. For example, a PS-AP protocol may be used to transfer to a UE Afrom the proximity server the identities of one or more other UEs Bdiscovered (e.g. by the proximity server) to be in proximity to the UE Afor particular proximity services supported by or of interest to boththe UE A and the UE(s) B. In certain implementations, a PS-AP protocolmay be used to transfer to the proximity server from a UE updates onproximity services required by the UE (e.g., updates to certainparameters for an already known proximity service for the UE or updatesconcerning new proximity services that the UE may use).

In certain example implementations, techniques may be implemented tosupport ProSe signaling in an LTE network or with LTE-D using a PDPprotocol Layer in association with a CP proximity server (e.g. asdescribed in association with FIG. 14 and FIG. 7), a UP proximity server(e.g. as described in association with FIG. 15 and FIG. 9) or LTE-Dsignaling (e.g. in association with the protocol layering shown in FIG.8). In certain example implementations, a PDP protocol may be used in anetwork mode to support discovery of proximity between UEs using a CP orUP proximity server (e.g., as described in association with FIG. 7and/or FIG. 9) by enabling exchange of proximity related informationbetween a UE and the CP or UP proximity server. Information may betransferred in both uplink and downlink directions by PDP in this caseto authenticate proximity services claimed to be of interest to orsupported by a UE (e.g. where proximity services claimed by a UE to beof interest or to be supported are compared to proximity servicessubscribed to by the UE that were transferred from the home HSS of theUE to the UE's serving MME. Information may also be transferred in anuplink direction by PDP (from a UE to a proximity server) that mayinclude one or more of the UE's identity and/or location, proximityservices of interest to the UE, the UE's current serving cell,information received directly by the UE from other UEs, and/or the UE'sLTE-D capabilities, just to name a few examples. In someimplementations, information may be transferred by PDP downlink (from aproximity server to a UE) that may include one or more of the identitiesof other UEs (e.g. UEs found to be in proximity to the recipient UE), apermission for the UE to use LTE-D mode and information regarding use ofan LTE-D mode by the recipient UE, again just to name a few examples.

With regard to use of PDP to support an LTE-D Mode (e.g. using theprotocol layering shown in FIG. 8), UEs may broadcast their identity ora pseudo-identity and proximity services of interest at an RRC level(e.g. with the protocol layering of FIG. 8), which may be passed up tothe PDP* level at a recipient UE. Once RRC establishes potential oractual proximity between a pair of UEs or a network proximity server hasinformed one or both UEs about actual or potential proximity, a UE mayuse PDP* to signal additional information to the other UE (e.g., viabroadcast or using an RRC signaling link previously established betweenthe pair of UEs). In certain instances, a PDP* protocol used by UEs inan LTE-D mode may be a variant of (e.g. an extension of) the PDPprotocol used between a UE and proximity server in network mode or maybe a different protocol.

In certain example implementations, techniques may be implemented forProximity Service Support via an Application (App) protocol layer—e.g.as applicable to the protocol layering described for FIG. 10. In certainimplementations, an App layer may be associated with individual ProSeApps and may be defined to support specific proximity services. Forexample, a particular application on a UE may support one or moreproximity services, may be notified by some other process on the UE(e.g. a process supporting the PDP protocol discussed previously herein)when proximity has been discovered with another UE supporting one ormore of the same proximity services and may then (e.g. under usercontrol) proceed to communicate using the App protocol layer with a peerapplication in the other UE to support one or more proximity services ofinterest to the users of both UEs. In certain instances, an App layermay provide peer to peer (P2P) communication between Apps on pairs ofUEs or on groups of three or more UEs. For UEs that make use of anetwork for communication (in network mode), an App layer may exchangeProtocol Data Units (PDUs) between Apps in different UEs using one ormore of IP bearers setup through the network, SMS, and/or SIP (via IMS),just to name a few examples. For UEs able to employ LTE-D mode forcommunication, an App layer may exchange PDUs between Apps in differentUEs using IP bearers setup directly between the UEs using LTE-D—e.g.,with protocol layering possibly as shown in FIG. 10. Alternatively, anApp layer could transfer PDUs between UEs in LTE-D mode using theprotocol layering shown in FIG. 8 but with an App protocol layerreplacing the PDP* layer shown in FIG. 8. In this case, App layer PDUtransfer may be based on NAS signaling support. In certainimplementations, an App layer may be used to negotiate setup ofcommunication between users, e.g., using speech, IM, video, etc., withcommunication conveyed either via a network or using LTE-D.

Attention is drawn next to FIG. 11, which illustrates example combinedprotocols 1100 that may be implemented to transmit, receive and/or relayinformation for use in supporting proximity services between two or moremobile devices, in accordance with an example implementation. Combinedprotocols 1100 illustrate an example architecture for LTE-D Mode thatcombines both CP protocols as in FIG. 8 with UP protocols as in FIG. 10.Included in example combined protocols 1100 are corresponding protocolstacks 1102 (for a first UE) and 1104 (for a second UE). As shown,example stacks 1102 and 1104 may comprise corresponding layers such asan L1, MAC, RLC, PDCP, IP, RRC, TCP/TLS, NAS, PDP*, and an App layer.These protocols may be the same as those described for FIGS. 8 and 10.

Example combined protocols 1100 shows how a UE may support a commonProSe App that manages ProSe discovery on behalf of other Apps in the UEthat are each specific to particular proximity services, e.g., such asPublic Safety and Friend Finder. The common ProSe App may be referred toas a ProSe engine or ProSe process and may (i) provide a commoninterface (e.g. via a common API) to other Apps on a UE that eachsupport different proximity services and (ii) enable these other Apps todetermine when their UE is in proximity to another UE containing thesame App and supporting the same proximity service(s). In certaininstances, the common ProSe App may employ PDP* or PDP (not shown inFIG. 11) and lower CP protocol layers for proximity discovery in eithernetwork mode (e.g. using the protocol layering of FIG. 7) or LTE-D mode(using the protocol layering shown in FIG. 8 and FIG. 11). In certaininstances, the common ProSe App may use NAS in order to set up UE-UEdata bearers or to exchange signaling messages at the CP level. Incertain instances, the common ProSe App may use the UP layers (as shownin FIG. 10 and FIG. 11) for exchanging voice, other media and data. Incertain implementations, the common ProSe App may use PDP and lowerlayer protocols to communicate with a network proximity server (notshown in FIG. 11 but as shown in FIG. 7 and/or FIG. 9,) if a UE is innetwork mode in order, for example, to discover proximity to other UEs.In certain instances, a pair of Apps supporting specific proximityservices for two UEs, that have been determined to be in proximity bytheir respective Common ProSe Apps, may communicate with one another inLTE-D mode via their respective common ProSe Apps. In this case, thecommon ProSe Apps may transfer App PDUs between the pair of Apps viaPDP* and NAS (e.g. using the protocol layering shown in FIG. 10) or viaTCP/TLS and IP (e.g. using the protocol layering shown in FIG. 10).Alternatively, the pair of Apps may communicate in LTE-D mode directly,not via the common ProSe Apps, by making direct use of either the NAS(CP) layer (e.g. as in FIG. 8 with an App layer replacing the PDP*layer) or the TCP/TLS/IP (UP) layers (e.g. as in FIG. 10). The protocolthat Apps may employ for communication via the common ProSe App or usingdirect communication is shown by the App layer dashed arrow 1106 in FIG.11.

Attention is now drawn to FIG. 12 and FIG. 13, which illustrate someexample protocols 1200 and 1300, respectively, that may be implementedto relay information between applications in two or more mobile devices,in accordance with an example implementation. For example, certaininformation may be relayed between ProSe Apps in LTE-D Mode. Exampleprotocols 1200 may be used to provide relaying of certain information atthe App Level, and example 1300 may be used to provide relaying ofcertain information at the IP Level. As shown, protocol 1200 may includea stack 1202 (for a first UE), a stack 1204 (for a relaying second UE),and a stack 1206 (for a third UE 3). Example stacks 1202, 1204 and 1206may comprise corresponding layers such as L1, MAC, RLC, PDCP, IP,TCP/TLS, and an App protocol layer (denoted by the term Appln). Asshown, protocols 1300 may include a stack 1302 (for a first UE), a stack1304 (for a relaying second UE), and a stack 1306 (for a third UE).Example stacks 1302 and 1306 may comprise corresponding layers such asL1, MAC, RLC, PDCP, IP, TCP/TLS, and Appln, and example stack 1304 maycomprise corresponding layers such as L1, MAC, RLC, PDCP, and IP. Theseprotocol layers may correspond to those described for FIG. 10.

For the protocol alternatives described for FIG. 11, signaling messages(e.g. App PDUs) may be transferred between Apps (as described above) (i)via the common ProSe App using PDP* and NAS or (ii) using TCP/TLS and IPor (iii) directly using NAS or TCP/TLS/IP. For UEs not able tocommunicate with one another directly via LTE-D but able to communicateusing LTE-D via one or more intermediate relay UEs, there may be somechoice as to how the relaying is performed—e.g. concerning the protocollayers that need to be intercepted by relay UEs as opposed to beingtransferred end to end without interception. Relaying may be performedat intermediate UEs at (i) the Appln level (e.g. as shown in FIG. 12) inwhich the App protocol layer and all lower layers may be intercepted andrelayed, (ii) at the PDP* level in which the PDP* layer and all lowerlayers (e.g. NAS, RRC, PDCP) may be intercepted and relayed, (iii) atthe NAS level in which NAS and all lower protocol layers may beintercepted and relayed or (iv) at the IP level (e.g. as shown in FIG.13) in which the IP layer and all lower layers may be intercepted andrelayed. In certain instances, communication (e.g. speech, IM, video)transferred between users associated with a ProSe App may be moreefficiently relayed at the IP level, e.g., as in FIG. 13.

In certain example implementations, a protocol layer at which relayingis performed may also be used to exchange information between nearby UEsto maintain information (in each UE) concerning which UEs may be indirect radio proximity with one another and via which intermediate relayUEs communication to other UEs may need to be routed. In certaininstances, it may be useful to manage routing/relaying at the App level,e.g., making relaying at the App level a possible implementationalternative. However, exchange of routing related information mayinstead be provided at the PDP* layer or possibly provided in a newprotocol associated with the NAS layer or IP layer, e.g., allowingrelaying at these protocol levels. In certain instances, broadcast andrelaying of basic information (e.g., as previously described inassociation with implicit and explicit acknowledgment and taggedtransmission) may be used to support relaying and exchange of routingrelated information. A result may be that relaying information asdescribed above (e.g. in association with FIGS. 12 and 13) at any levelmay be combined with the hop by hop routing method described earlier. Inaddition, relaying at the App level may be combined with efficientrelaying described earlier using implicit or explicit acknowledgment,tagged transmission or source routing; and relaying information at thePDP* level or NAS level may be combined with source routing.

FIG. 17 is a schematic diagram of a UE according to an implementation.UE 100 (FIG. 1) may comprise one or more features of UE 1700 shown inFIG. 17. In certain implementations, UE 1700 may also comprise awireless transceiver 1721 which is capable of transmitting and receivingwireless signals 1723 via wireless antenna 1722 over a wirelesscommunication network. Wireless transceiver 1721 may be connected to bus1701 by a wireless transceiver bus interface 1720. Wireless transceiverbus interface 1720 may, in some implementations be at least partiallyintegrated with wireless transceiver 1721. Some implementations mayinclude multiple wireless transceivers 1721 and wireless antennas 1722to enable transmitting and/or receiving signals according to acorresponding multiple wireless communication standards such as, forexample, versions of IEEE Std. 802.11, CDMA, WCDMA, LTE, UMTS, GSM,AMPS, Zigbee and Bluetooth, just to name a few examples.

UE 1700 may also comprise SPS receiver 1755 capable of receiving andacquiring SPS signals 1759 via SPS antenna 1758. SPS receiver 1755 mayalso process, in whole or in part, acquired SPS signals 1759 forestimating a location of UE 1700. In some implementations,general-purpose processor(s) 1711, memory 1740, DSP(s) 1712 and/orspecialized processors (not shown) may also be utilized to processacquired SPS signals, in whole or in part, and/or calculate an estimatedlocation of UE 1700, in conjunction with SPS receiver 1755. Storage ofSPS or other signals for use in performing positioning operations may beperformed in memory 1740 or registers (not shown).

Also shown in FIG. 17, UE 1700 may comprise digital signal processor(s)(DSP(s)) 1712 connected to the bus 1701, general-purpose processor(s)1711 connected to the bus 1701, and memory 1740. In certainimplementations bus interface(s) (not shown) may be integrated with theDSP(s) 1712, general-purpose processor(s) 1711 and memory 1740. Invarious implementations, functions may be performed in response toexecution of one or more machine-readable instructions stored in memory1740 such as on a computer-readable storage medium, such as RAM, ROM,FLASH, or disc drive, just to name a few example. The one or moreinstructions may be executable by general-purpose processor(s) 1711,specialized processors, or DSP(s) 1712. Memory 1740 may comprise anon-transitory processor-readable memory and/or a computer-readablememory that stores software code (programming code, instructions, etc.)that are executable by processor(s) 1711 and/or DSP(s) 1712 to performfunctions described herein.

Also shown in FIG. 17, a user interface 1735 may comprise any one ofseveral devices such as, for example, a speaker, microphone, displaydevice, vibration device, keyboard, touch screen, just to name a fewexamples. In a particular implementation, user interface 1735 may enablea user to interact with one or more applications hosted on UE 1700. Suchapplications (or Apps) may contain software stored in memory 1740 andrun on processor(s) 1711 and/or or on DSP(s) 1712. For example, devicesof user interface 1735 may store analog or digital signals on memory1740 to be further processed by DSP(s) 1712 or general purpose processor1711 in response to action from a user. Similarly, applications hostedon UE 1700 may store analog or digital signals on memory 1740 to presentan output signal to a user. In another implementation, UE 1700 mayoptionally include a dedicated audio input/output (I/O) device 1770comprising, for example, a dedicated speaker, microphone, digital toanalog circuitry, analog to digital circuitry, amplifiers and/or gaincontrol. It should be understood, however, that this is merely anexample of how an audio I/O may be implemented in a UE, and that claimedsubject matter is not limited in this respect. In anotherimplementation, UE 1700 may comprise touch sensors 1762 responsive totouching or applying pressure on a keyboard or touch screen device.

UE 1700 may also comprise a dedicated camera device 1764 for capturingstill or moving imagery. Camera device 1764 may comprise, for example animaging sensor (e.g., charge coupled device or CMOS imager), lens,analog to digital circuitry, frame buffers, just to name a few examples.In one implementation, additional processing, conditioning, encoding orcompression of signals representing captured images may be performed atgeneral purpose processor 1711 or DSP(s) 1712. Alternatively, adedicated video processor 1768 may perform conditioning, encoding,compression or manipulation of signals representing captured images.Additionally, video processor 1768 may decode/decompress stored imagedata for presentation on a display device (not shown) on UE 1700.

UE 1700 may also comprise sensors 1760 coupled to bus 1701 which mayinclude, for example, inertial sensors and environment sensors. Inertialsensors of sensors 1760 may comprise, for example accelerometers (e.g.,collectively responding to acceleration of UE 1700 in three dimensions),one or more gyroscopes or one or more magnetometers (e.g., to supportone or more compass applications). Environment sensors of UE 1700 maycomprise, for example, temperature sensors, barometric pressure sensors,ambient light sensors, camera imagers, microphones, just to name fewexamples. Sensors 1760 may generate analog or digital signals that maybe stored in memory 1740 and processed by DPS(s) or general purposeprocessor 1711 in support of one or more applications such as, forexample, applications directed to positioning or navigation operations.

In a particular implementation, a digital map of an indoor area may bestored in a particular format in memory 1740. The digital map may havebeen obtained from messages containing navigation assistance data from aremote server. General purpose processor 1711 may execute instructionsto processes the stored digital map to identify and classify componentareas bounded by a perimeter of structures indicated in the digital map.These executed instructions may specify identifying and characterizingegress segments in structures forming a perimeter bounding a componentarea and classifying the bounded component area based, at least in part,on a proportionality of a size of at least one identified egress segmentto a size of at least one dimension of the bounded component area. Inone implementation, a UE may further apply crowed sourced data (e.g.,obtained from a location server) to confirm an inferences of an egresssegment. For example, if there is a history of UEs moving through afeature presumed to be an egress segment, the feature may be confirmedas providing an egress segment.

In a particular implementation, UE 1700 may comprise a dedicated modemprocessor 1766 capable of performing baseband processing of signalsreceived and downconverted at wireless transceiver 1721 or SPS receiver1755. Similarly, modem processor 1766 may perform baseband processing ofsignals to be upconverted for transmission by wireless transceiver 1721.In alternative implementations, instead of having a dedicated modemprocessor, baseband processing may be performed by a general purposeprocessor or DSP (e.g., general purpose processor 1711 or DSP(s) 1712).It should be understood, however, that these are merely examples ofstructures that may perform baseband processing, and that claimedsubject matter is not limited in this respect.

FIG. 18 is a schematic diagram illustrating an example system 1800 thatmay include one or more devices configurable to implement techniques orprocesses described above, for example, in connection with FIG. 1.System 1800 may include, for example, a first device 1802, a seconddevice 1804, and a third device 1806, which may be operatively coupledtogether through a single wireless communications network 1808 orthrough several interconnected serving wireless communicationnetworks—e.g. a different serving network for each device (not shown inFIG. 18). In an aspect, first device 1802 may comprise a server capableof providing positioning assistance data such as, for example, a basestation almanac. First device 1802 may also comprise a server capable ofproviding indoor positioning assistance data relevant to a locationspecified in a request from a UE. First device 1802 and/or second device1804 may also comprise a Proximity server such as CP Proximity server708 in FIG. 7, UP Proximity server 910 in FIG. 9, Proximity server 1408in FIG. 14. Proximity server 1512 in FIG. 15 and Proximity server 1622in FIG. 16. Second device 1804 and third device 1806 may comprise UEs,in an aspect. Also, in an aspect, wireless communications network 1808may comprise one or more wireless access points, for example. However,claimed subject matter is not limited in scope in these respects.

First device 1802, second device 1804 and third device 1806, as shown inFIG. 18, may be representative of any device, appliance or machine(e.g., such as local transceiver 115 or servers 140, 150 or 155 as shownin FIG. 1) that may be configurable to exchange data over wirelesscommunications network 1808. By way of example but not limitation, anyof first device 1802, second device 1804, or third device 1806 mayinclude: one or more computing devices or platforms, such as, e.g., adesktop computer, a laptop computer, a workstation, a server device, orthe like; one or more personal computing or communication devices orappliances, such as, e.g., a personal digital assistant, mobilecommunication device, or the like; a computing system or associatedservice provider capability, such as, e.g., a database or data storageservice provider/system, a network service provider/system, an Internetor intranet service provider/system, a portal or search engine serviceprovider/system, a wireless communication service provider/system; orany combination thereof. Any of the first device 1802, second device1804, and/or third device 1806, may comprise one or more of a basestation almanac server, a base station, or a UE in accordance with theexamples described herein.

Similarly, wireless communications network 1808 (e.g., in a particularof implementation of network 130 shown in FIG. 1), may be representativeof one or more communication links, processes, or resources configurableto support the exchange of data between at least two of first device1802, second device 1804, and third device 1806. By way of example butnot limitation, wireless communications network 1808 may includewireless or wired communication links, telephone or telecommunicationssystems, data buses or channels, optical fibers, terrestrial or spacevehicle resources, local area networks, wide area networks, intranets,the Internet, routers or switches, and the like, or any combinationthereof. As illustrated, for example, by the dashed lined boxillustrated as being partially obscured of third device 1806, there maybe additional like devices operatively coupled to wirelesscommunications network 1808.

It is recognized that all or part of the various devices and networksshown in system 1800, and the processes and methods as further describedherein, may be implemented using or otherwise including hardware,firmware, software, or any combination thereof.

Thus, by way of example but not limitation, second device 1804 mayinclude at least one processing unit 1820 that is operatively coupled toa memory 1822 through a bus 1828.

Processing unit 1820 is representative of one or more circuitsconfigurable to perform at least a portion of a data computing procedureor process. By way of example but not limitation, processing unit 1820may include one or more processors, controllers, microprocessors,microcontrollers, application specific integrated circuits, digitalsignal processors, programmable logic devices, field programmable gatearrays, and the like, or any combination thereof.

Memory 1822 is representative of any data storage mechanism. Memory 1822may include, for example, a primary memory 1824 or a secondary memory1826. Primary memory 1824 may include, for example, a random accessmemory, read only memory, etc. While illustrated in this example asbeing separate from processing unit 1820, it should be understood thatall or part of primary memory 1824 may be provided within or otherwiseco-located/coupled with processing unit 1820.

In a particular implementation, information received from mobile devicesand/or from elements in network 1808 related to proximity between mobiledevices and/or proximity services supported by mobile devices may bestored in a particular format in memory 1822. Processing unit 1820 mayexecute instructions to processes the stored proximity relatedinformation—e.g. in order to discover proximity between mobile devicesand notify mobile devices of any discovered proximity.

Secondary memory 1826 may include, for example, the same or similar typeof memory as primary memory or one or more data storage devices orsystems, such as, for example, a disk drive, an optical disc drive, atape drive, a solid state memory drive, etc. In certain implementations,secondary memory 1826 may be operatively receptive of, or otherwiseconfigurable to couple to, a computer-readable medium 1840.Computer-readable medium 1840 may include, for example, anynon-transitory medium that can carry or make accessible data, code orinstructions for one or more of the devices in system 1800.Computer-readable medium 1840 may also be referred to as a storagemedium.

Second device 1804 may include, for example, a communication interface1830 that provides for or otherwise supports the operative coupling ofsecond device 1804 to at least wireless communications network 1808. Byway of example but not limitation, communication interface 1830 mayinclude a network interface device or card, a modem, a router, a switch,a transceiver, and the like.

Second device 1804 may include, for example, an input/output device1832. Input/output device 1832 is representative of one or more devicesor features that may be configurable to accept or otherwise introducehuman or machine inputs, or one or more devices or features that may beconfigurable to deliver or otherwise provide for human or machineoutputs. By way of example but not limitation, input/output device 1832may include an operatively configured display, speaker, keyboard, mouse,trackball, touch screen, data port, etc.

FIG. 19A and FIG. 19B are flow diagrams illustrating some exampleprocesses 1900 and 1900′, respectively, that may be implemented within acomputing device (e.g. UE 1700 or system 1800), e.g., to supportproximity services. At example block 1902, the computing device maydetermine whether a first mobile device and a second mobile device areeach operatively provisioned to make use of a common proximity service.At example block 1904, the computing device may determine whether astate of proximity between the first mobile device and the second mobiledevice is expected to occur at a future time. Here, for example, atblock 1906 in FIG. 19B the computing device may consider a current orpast motion state of at least one of the mobile devices, and/or at block1908 in FIG. 19B the computing device may consider a historic behaviorof at least one of the mobile devices, and/or at block 1910 in FIG. 19Bthe computing device may consider an identification that the mobiledevices are in a common venue.

At example block 1912, the computing device may initiate notification ofa user and/or an application of at least one of the mobile devices thata state of proximity with the other mobile device has occurred or willoccur. Here, for example, at block 1914 in FIG. 19B the computing devicemay determine a probability, and/or a time interval for which theproximity is expected to occur at the future time, and at block 1916 inFIG. 19B initiate notification of the user and/or the application inresponse to the probability exceeding a probability threshold, and/orthe time interval falling below a time threshold.

In certain example implementations, at least one of the current and pastmotion state of the at least one of the first or second mobile devicesmay comprise at least one of a geographic location and a velocity.

In certain example implementations, the historic behavior of the atleast one of the first or second mobile devices may be determined, atleast in part, based on a location history of the at least one of thefirst or second mobile devices. In certain instances, the historicbehavior may be based, at least in part, on at least one of a currentlocation of the at least one of the first or second mobile devices and acurrent day and/or a time.

The methodologies described herein may be implemented by various meansdepending upon applications according to particular examples. Forexample, such methodologies may be implemented in hardware, firmware,software, or combinations thereof. In a hardware implementation, forexample, a processing unit may be implemented within one or moreapplication specific integrated circuits (“ASICs”), digital signalprocessors (“DSPs”), digital signal processing devices (“DSPDs”),programmable logic devices (“PLDs”), field programmable gate arrays(“FPGAs”), processors, controllers, micro-controllers, microprocessors,electronic devices, other devices units designed to perform thefunctions described herein, or combinations thereof.

Some portions of the detailed description included herein are presentedin terms of algorithms or symbolic representations of operations onbinary digital signals stored within a memory of a specific apparatus orspecial purpose computing device or platform. In the context of thisparticular specification, the term specific apparatus or the likeincludes a general purpose computer once it is programmed to performparticular operations pursuant to instructions from program software.Algorithmic descriptions or symbolic representations are examples oftechniques used by those of ordinary skill in the signal processing orrelated arts to convey the substance of their work to others skilled inthe art. An algorithm is here, and generally, is considered to be aself-consistent sequence of operations or similar signal processingleading to a desired result. In this context, operations or processinginvolve physical manipulation of physical quantities. Typically,although not necessarily, such quantities may take the form ofelectrical or magnetic signals capable of being stored, transferred,combined, compared or otherwise manipulated. It has proven convenient attimes, principally for reasons of common usage, to refer to such signalsas bits, data, values, elements, symbols, characters, terms, numbers,numerals, or the like. It should be understood, however, that all ofthese or similar terms are to be associated with appropriate physicalquantities and are merely convenient labels. Unless specifically statedotherwise, as apparent from the discussion herein, it is appreciatedthat throughout this specification discussions utilizing terms such as“processing,” “computing,” “calculating,” “determining” or the likerefer to actions or processes of a specific apparatus, such as a specialpurpose computer, special purpose computing apparatus or a similarspecial purpose electronic computing device. In the context of thisspecification, therefore, a special purpose computer or a similarspecial purpose electronic computing device is capable of manipulatingor transforming signals, typically represented as physical electronic ormagnetic quantities within memories, registers, or other informationstorage devices, transmission devices, or display devices of the specialpurpose computer or similar special purpose electronic computing device.

Wireless communication techniques described herein may be in connectionwith various wireless communications networks such as a wireless widearea network (“WWAN”), a wireless local area network (“WLAN”), awireless personal area network (WPAN), and so on. The term “network” and“system” may be used interchangeably herein. A WWAN may be a CodeDivision Multiple Access (“CDMA”) network, a Time Division MultipleAccess (“TDMA”) network, a Frequency Division Multiple Access (“FDMA”)network, an Orthogonal Frequency Division Multiple Access (“OFDMA”)network, a Single-Carrier Frequency Division Multiple Access (“SC-FDMA”)network, or any combination of the above networks, and so on. A CDMAnetwork may implement one or more radio access technologies (“RATS”)such as cdma2000, Wideband-CDMA (“W-CDMA”), to name just a few radiotechnologies. Here, cdma2000 may include technologies implementedaccording to IS-95, IS-2000, and IS-856 standards. A TDMA network mayimplement Global System for Mobile Communications (“GSM”), DigitalAdvanced Mobile Phone System (“D-AMPS”), or some other RAT. GSM andW-CDMA are described in documents from a consortium named “3rdGeneration Partnership Project” (“3GPP”). Cdma2000 is described indocuments from a consortium named “3rd Generation Partnership Project 2”(“3GPP2”). 3GPP and 3GPP2 documents are publicly available. 4G Long TermEvolution (“LTE”) communications networks may also be implemented inaccordance with claimed subject matter, in an aspect. A WLAN maycomprise an IEEE 802.11x network, and a WPAN may comprise a Bluetoothnetwork, an IEEE 802.15x, for example. Wireless communicationimplementations described herein may also be used in connection with anycombination of WWAN, WLAN or WPAN.

In another aspect, as previously mentioned, a wireless transmitter oraccess point may comprise a femtocell, utilized to extend cellulartelephone service into a business or home. In such an implementation,one or more UEs may communicate with a femtocell via a code divisionmultiple access (“CDMA”) cellular communication protocol, for example,and the femtocell may provide the UE access to a larger cellulartelecommunication network by way of another broadband network such asthe Internet.

In the preceding detailed description, numerous specific details havebeen set forth to provide a thorough understanding of claimed subjectmatter. However, it will be understood by those skilled in the art thatclaimed subject matter may be practiced without these specific details.In other instances, methods and apparatuses that would be known by oneof ordinary skill have not been described in detail so as not to obscureclaimed subject matter.

The terms, “and”, “or”, and “and/or” as used herein may include avariety of meanings that also are expected to depend at least in partupon the context in which such terms are used. Typically, “or” if usedto associate a list, such as A, B or C, is intended to mean A, B, and C,here used in the inclusive sense, as well as A, B or C, here used in theexclusive sense. In addition, the term “one or more” as used herein maybe used to describe any feature, structure, or characteristic in thesingular or may be used to describe a plurality or some othercombination of features, structures or characteristics. Though, itshould be noted that this is merely an illustrative example and claimedsubject matter is not limited to this example.

While there has been illustrated and described what are presentlyconsidered to be example features, it will be understood by thoseskilled in the art that various other modifications may be made, andequivalents may be substituted, without departing from claimed subjectmatter. Additionally, many modifications may be made to adapt aparticular situation to the teachings of claimed subject matter withoutdeparting from the central concept described herein. Therefore, it isintended that claimed subject matter not be limited to the particularexamples disclosed, but that such claimed subject matter may alsoinclude all aspects falling within the scope of appended claims, andequivalents thereof.

What is claimed is:
 1. A method of supporting proximity services for amobile device comprising: determining whether a first mobile device anda second mobile device are each operatively provisioned to make use of acommon proximity service; determining whether a state of proximitybetween the first mobile device and the second mobile device is expectedto occur at a future time based at least in part on at least one of: acurrent or past motion state of at least one of the first mobile deviceor the second mobile device, a historic behavior of at least one of thefirst mobile device or the second mobile device, and/or anidentification that the first mobile device and the second mobile deviceare in a common venue; and initiating notification of a user and/or anapplication of at least one of the first mobile device or the secondmobile device that the state of proximity has occurred or will occur. 2.The method of claim 1, and further comprising: determining at least oneof: a probability, and/or a time interval for which the state ofproximity is expected to occur at the future time; and initiatingnotification of the user and/or the application in response to at leastone of: the probability exceeding a probability threshold, and/or thetime interval falling below a time threshold.
 3. The method of claim 1,wherein at least one of the current and past motion state of the atleast one of the first or second mobile devices comprises at least oneof a geographic location and a velocity.
 4. The method of claim 1,wherein the historic behavior of the at least one of the first or secondmobile devices is determined, at least in part, on a location history ofthe at least one of the first or second mobile devices.
 5. The method ofclaim 4, wherein the historic behavior is based, at least in part, on atleast one of a current location of the at least one of the first orsecond mobile devices and a current day and/or a time.
 6. The method ofclaim 4, wherein the location history is stored in the at least one ofthe first or second mobile devices.
 7. An apparatus for supportingproximity services, the apparatus comprising: means for determiningwhether a first mobile device and a second mobile device are eachoperatively provisioned to make use of a common proximity service; meansfor determining whether a state of proximity between the first mobiledevice and the second mobile device is expected to occur at a futuretime based at least in part on at least one of: a current or past motionstate of at least one of the first mobile device or the second mobiledevice, a historic behavior of at least one of the first mobile deviceor the second mobile device, and/or an identification that the firstmobile device and the second mobile device are in a common venue; andmeans for initiating notification of a user and/or an application of atleast one of the first mobile device or the second mobile device thatthe state of proximity has occurred or will occur.
 8. The apparatus ofclaim 7, and further comprising: means for determining at least one of:a probability, and/or a time interval for which the state of proximityis expected to occur at the future time; and wherein the means forinitiating notification of the user and/or the application, is responseto at least one of: the probability exceeding a probability threshold,and/or the time interval falling below a time threshold.
 9. Theapparatus of claim 7, wherein at least one of the current and pastmotion state of the at least one of the first or second mobile devicescomprises at least one of a geographic location and a velocity.
 10. Theapparatus of claim 7, wherein the historic behavior of the at least oneof the first or second mobile devices is determined, at least in part,on a location history of the at least one of the first or second mobiledevices.
 11. The apparatus of claim 10, wherein the historic behavior isbased, at least in part, on at least one of a current location of the atleast one of the first or second mobile devices and a current day and/ora time.
 12. The apparatus of claim 10, wherein the location history isstored in the at least one of the first or second mobile devices.
 13. Acomputing device for supporting proximity services, the computing devicecomprising: memory; and a processor to: determine whether a first mobiledevice and a second mobile device are each operatively provisioned tomake use of a common proximity service; determine whether a state ofproximity between the first mobile device or the second mobile device isexpected to occur at a future time based at least in part on at leastone of: a current or past motion state of at least one of the firstmobile device or the second mobile device, a historic behavior of atleast one of the first or second mobile devices, and/or anidentification that the first mobile device and the second mobile deviceare in a common venue; and initiate notification of a user and/or anapplication of at least one of the first mobile device or the secondmobile device that the state of proximity has occurred or will occur.14. The computing device of claim 13, the processor to further:determine at least one of: a probability, and/or a time interval forwhich the state of proximity is expected to occur at the future time;and initiate notification of the user and/or the application in responseto at least one of: the probability exceeding a probability threshold,and/or the time interval falling below a time threshold.
 15. Thecomputing device of claim 13, wherein at least one of the current andpast motion state of the at least one of the first or second mobiledevices comprises at least one of a geographic location and a velocity.16. The computing device of claim 13, wherein the historic behavior ofthe at least one of the first or second mobile devices is determined, atleast in part, on a location history of the at least one of the first orsecond mobile devices.
 17. The computing device of claim 16, wherein thehistoric behavior is based, at least in part, on at least one of acurrent location of the at least one of the first or second mobiledevices and a current day and/or a time.
 18. The computing device ofclaim 16, wherein the location history is stored in the at least one ofthe first or second mobile devices.
 19. An article for use in supportingproximity services, the article comprising: a non-transitory computerreadable medium having stored therein computer implementableinstructions executable by a processor of a computing device to:determine whether a first mobile device and a second mobile device areeach operatively provisioned to make use of a common proximity service;determine whether a state of proximity between the first mobile deviceand the second mobile device is expected to occur at a future time basedat least in part on at least one of: a current or past motion state ofat least one of the first mobile device or the second mobile device, ahistoric behavior of at least one of the first mobile device or thesecond mobile device, and/or an identification that the first mobiledevice and the second mobile device are in a common venue; and initiatenotification of a user and/or an application of at least one of thefirst mobile device or the second mobile device that the state ofproximity has occurred or will occur.
 20. The article of claim 19, thecomputer implementable instructions being further executable by theprocessor to: determine at least one of: a probability, and/or a timeinterval for which the state of proximity is expected to occur at thefuture time; and initiate notification of the user and/or theapplication in response to at least one of: the probability exceeding aprobability threshold, and/or the time interval falling below a timethreshold.
 21. The article of claim 19, wherein at least one of thecurrent and past motion state of the at least one of the first or secondmobile devices comprises at least one of a geographic location and avelocity.
 22. The article of claim 19, wherein the historic behavior ofthe at least one of the first or second mobile devices is determined, atleast in part, on a location history of the at least one of the first orsecond mobile devices.
 23. The article of claim 22, wherein the historicbehavior is based, at least in part, on at least one of a currentlocation of the at least one of the first or second mobile devices and acurrent day and/or a time.